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ABSTRACT 


This  software  functional  description  contains  performance  require¬ 
ments  and  functional  descriptions  of  the  application  and  system  software 
required  to  support  automated  Intelligence  Preparation  of  the  Battlefield 
( IPB(A) )  functions  in  an  All  Source  Analysis  System  (ASAS),  as  currently 
defined  by  USAICS.  The  ASAS  is  a  land-mobile,  tactical  intelligence 
processing  center  planned  for  Army  deployment  during  the  mid  to  late 
1980's. 


The  functional  descriptions  were  developed  for  the  Battlefield 
Systems  Integration  Directorate  of  USA  DARCOM  and  are  based  on  experience 
gained  in  the  development  and  demonstration  of  laboratory  capabilities 
during  the  IPB(A)  Phase  II  period  concluded  in  January  1980.  The 
functions  are  described  in  terms  such  that  there  is  no  dependency  on 
specific  commercial  hardware  or  software. 
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SECTION  1 .  SCOPE 


This  software  functional  description  contains  performance 
requirements  and  function  descriptions  of  the  application  and  system 
software  required  to  support  automated  Intelligence  Preparation  of 
the  Battlefield  (IPB)  functions  in  an  All  Source  Analysis  System 
(ASAS),  as  currently  defined  by  USAICS.  The  ASAS  is  a  land-mobile, 
tactical  intelligence  processing  center  planned  for  Army  deployment 
during  the  mid  to  late  1980* s. 

This  document  was  developed  for  the  Battlefield  Systems  Integra¬ 
tion  Directorate  of  USA  DAPXOM  during  the  IPB(A)  Phase  II  period 
starting  21  March  1979  and  concluding  in  January,  1980.  The  functional 
descriptions  are  based  on  experience  gained  in  the  development  and 
demonstration  of  laboratory  capabilities  during  this  contract.  The 
functions  are  described  in  terms  such  that  there  Is  no  dependency  on 
specific  commercial  hardware  or  software. 


SECTION  2.  APPLICABLE  DOCUMENTS 


The  documents  utilized  in  the  development  of  the  functional 
descriptions  include: 

1.  Tactical  Intelligence  Applications  Experimentation  (TIAX) 
Report,  Phase  A  Final  Report,  prepared  by  IBM  Federal 
Systems  Division,  dated  20  October  1978. 

2.  Tactical  Intelligence  Applications  Experimentation  (TIAX) 
Review,  prepared  by  IBM  Federal  Systems  Division,  dated 

6  June  1979. 

3.  Tactical  Intelligence  Applications  Experimentation  (TIAX) 
Report,  Phase  II  Interim  Report,  prepared  by  IBM  Federal 
Systems  Division,  dated  17  August  1979. 

4.  Draft  Training  Circular  No.  30-27  dated  1  August  1979 
entitled  Intelligence  Preparation  of  the  Battlefield. 

5.  FM  30-102,  Opposing  Forces,  Europe. 

6.  FM  100-5,  dated  1  July  1976  entitled  Operations. 

-  *■**“"*  y 

7.  FM  21-30,  Military  Symbols. 

8.  IAG-13-U-78,  Soviet  Army  Operations,  U.S.  Army  Intelligence 
and  Security  Command  Intelligence  and  Threat  Analysis  Center 
dated  April  1979. 
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9.  FM  30-5,  Combat  Intelligence  dated  October  1973. 

10.  FM  30-40,  Handbook  on  Soviet  Ground  Forces  dated 
30  June  1975. 

11.  DDI -1 1 20-10-77 ,  Soviet  Tank  Battalion  Tactics,  Defense 
Intelligence  Agency  dated  August,  1977. 

12.  FM  30-10,  Military  Geographic  Intelligence  (Terrain)  dated 
March,  1972. 

13.  TC  30-11,  Army  Tactical  Weather  dated  April,  1977. 

14.  FM  6-20,  Field  Artillery  Tactics  and  Operations. 

15.  FM  101-5,  Command  and  Control  of  Combat  Operations. 

16.  An  Analytical  Approach  to  Terrain  Analysis  and  Allocation  of 
Combat  Power,  prepared  by  U.S.  Army  Intelligence  Center  and 
School,  dated  May  1978. 
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SECTION  3.  FUNCTIONAL  REQUIREMENTS 


This  section  addresses  the  software  functional  requirements 
necessary  to  support  IPB  functions  in  the  ASAS.  It  includes  intro¬ 
ductory  material  that  places  the  IPB  analyst  position  in  an  ADP 
system  environment  and  describes  an  operational  context  in  which 
the  system  will  function.  A  brief  summary  of  the  IPB  operational 
concept  is  also  covered  (for  further  details  refer  to  Tactical 
Intelligence  Applications  Experimentation  (TIAX)  Report,  Phase  A 
Final  Report,  dated  20  October  1978). 

Although  the  "system  to  support  the  IPB  analyst"  is  mentioned 
throughout  please  note  that  IPB  will  not  be  supported  by  a  stand¬ 
alone  system;  rather,  this  functional  description  assumes  that  IPB 
will  be  one  of  many  functions  to  be  supported  by  the  ASAS. 

IPB  Operational  Concept 

Figure  3-1  illustrates  how  preplanned  IPB  products  are  utilized 
during  hostilities  to  supDort  the  G-2's  develonment  of  the  realtime 
intelligence  estimate  and  to  focus  collection  resources  on  higher 
yield  areas  of  interest. 

The  upper  right  portion  of  Figure  3-1  shows  the  process  of 
receiving  intelligence  inputs  and  developing  the  current  situation 
display  through  correlation  and  fusion  processes.  This  is  assumed 
to  be  a  continuous  process  of  receiving  Inputs,  assessing  their 
significance  to  the  current  military  situation,  and  updating  the 
military  situation  display  If  warranted.  This  function  will  be 
performed  tv  the  current  situation  analyst  In  the  ASAS  with  the 
resulting  display  being  provided  to  the  IPB  analyst's  station  as 
well  as  others  in  the  CRT  form. 
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Figure  3-1.  Operational  Concept 
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The  IPB  products  (developed  during  the  battle  planninq  phase)  are 
shown  on  the  left  side  of  the  illustration.  In  the  realtime  process 
the  IPB  analyst  is  constantly  searchino  his  situation  templates  file 
tryinq  to  match  one  with  the  current  real  time  situation  display.  This 
is  a  visual  comparison  process.  He  does  not  expect  to  find  an  exact 
match,  and  will  frequently  draw  on  his  other  IPB  files  (snapshots, 
doctrinal  templates,  terrain  overlays,  etc.)  to  try  to  rationalize' 
observed  differences  in  the  situation  displays.  When  he  thinks  he  may 
have  a  match,  his  first  actions  are  to  try  to  confirm  his  hypothesis. 

He  does  this  by  accessinq  his  event  templates  and  event  matrixes  to 
determine  what  enemy  activities  should  be  observable  in  the  next  few 
hours  if  the  enemy  is  indeed  at  the  point  in  his  option  that  the  analyst 
suspects.  He  next  requests  that  collection  resources  place  a  priority 
on  collectinq  data  about  the  events  selected  from  his  event  matrix  in 
the  sequence  and  at  the  locations  (NAIs)  indicated.  He  cues  the  input 
processinq  system  to  alert  him  Immediately  upon  receipt  of  any  returns 
to  these  specific  collection  requests.  He  further  places  a  time  limit 
on  how  lonq  he  is  willinq  to  wait  to  receive  verifyinq  information.  If 
the  system  notifies  him  that  no  confirming  data  has  been  received  by  the 
specified  time,  he  would  probably  drop  that  hypothesis.  Several  of  these 
hypotheses  may  be  working  in  parallel  with  one  another.  Thus,  system 
support  in  eliminating  those  that  are  not  verified  would  be  helpful. 

When  confirming  data  is  received  that  anticipated  events  have 
indeed  been  observed,  the  probability  is  sionif icantly  increased  that 
the  enemy  has  been  detected  in  a  certain  option  and  at  a  specific  point 
in  that  option.  The  analyst  can  therefore  proceed  more  positively  to 
exploit  that  knowledge.  Toward  developing  an  intelligence  estimate, 
the  analyst  references  his  snapshot  file,  selects  one  several  hours 
hence,  and  updates  it  based  on  current  situation  knowledge.  This  forms 
the  basis  of  the  estimate  of  where  the  enemy  will  be,  at  what  time,  and 
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In  what  strength  If  he  continues  in  the  option  he  Is  presently  pur¬ 
suing  with  terrain  and  weather  already  taken  Into  account.  This  graphic 
would  be  used  to  brief  the  commander  so  that  appropriate  countermoves 
can  be  initiated.  In  addition,  event  templates  can  be  exploited  to  not 
only  focus  collection  resources  again  but  also  notify  the  Fire  Support 
Element  (FSE)  of  what  targets  can  be  expected  at  which  locations  over 
the  next  several  hours.  Preplanned  operations  orders  can  be  finalized 
for  deployment  of  friendly  forces  to  meet  the  enemy.  Terrain  analyses 
completed  in  advance  by  the  G-2  staff  would  be  available  to  the  FSE  and 
maneuver  sections  for  support  in  planning  fires  allocation  and  friendly 
force  movements  to  Interdict. 

Although  certain  IPB  techniques  can  be  usefully  applied  at  any 
echelon,  the  concept  presented  here  Is  felt  to  be  most  practical  at 
echelons  no  lower  than  division,  where  larqer  enemy  force  elements 
must  be  monitored,  and  where  a  reasonable  automated  data  processing 
capability  will  be  resident  In  the  center.  Also,  the  continuation  of 
this  basic  process  throughout  a  battle  situation  demands  local  ability 
to  modify  the  IPB  products  stored  in  the  system,  and  to  develop  new 
ones  as  enemy  courses  of  action  vary. 

Time  Phasing  of  IPB  Activities 

Figure  3-2  illustrates  the  general  time  relationships  of  the  major 
IPB  areas  of  activity.  Long  prior  to  hostilities  for  known  areas  of 
concern,  support  agencies  will  have  developed  basic  map  data,  terrain 
data,  and  doctrinal  data  In  a  form  tailored  to  an  operational  mission. 

It  would  Include  map  and  terrain  data  for  the  assigned  area  of  interest 
and  doctrinal  data  for  the  enemy  expected  to  be  encountered,  but  would 
be  Independent  of  the  specifics  of  the  military  situation.  The  data 
would  be  provided  In  machine  readable  form,  and  would  be  "provisioned" 
to  the  operating  forces  upon  departure.  If  the  mission  Involved  an 


Figure  3-2.  IPB  Time  Phasing 


area  of  the  world  for  which  limited  data  is  available,  the  data 
preparation  phase  would  be  much  closer  in  time  to  the  hostilities 
phase. 

As  the  operating  forces  approach  their  destination,  the  Battle 
Planning  Phase  would  begin.  Based  on  command  guidance  regarding  enemy 
options  for  which  to  plan,  IPB  product  sets  for  each  option  would  be 
built.  The  early  portions  of  the  build  phase  would  involve  terrain 
analyses  to  define  mobility  corridors,  and  then  enemy  templating  to 
fit  enemy  forces  to  the  terrain.  It  is  durinq  this  phase  that  many  of 
the  special  automation  aids  to  the  analyst  described  in  this  document 
come  to  play,  enabling  IPB  graphics  to  be  built  rapidly.  The  results 
of  the  planning  phase  are  the  standard  IPB  products  listed  in  the 
Illustration.  They  would  be  stored  in  the  system  for  use  during  the 
hostilities  phase. 

The  hostilities  phase  commences  upon  indications  that  enemy  move¬ 
ments  toward  attack  have  begun.  Early  in  this  phase  the  G-2  staff  is 
using  Its  various  intelligence  resources  to  monitor  enemy  activity, 
looking  for  indications  of  initial  movement  to  attack.  The  G-2  staff 
Is  also  using  IPB  products  developed  during  the  planning  phase  to 
assist  in  recognizing  the  enemy  forces  detected  (see  Fiqure  3-1,  IPB 
'  Operational  Concept).  It  Is  durinq  this  part  of  the  hostilities  phase 
that  IPB  products  will  be  of  significant  value  to  the  G-2  in  (1)  inter¬ 
grating  the  current  situation  display,  (2)  recognizing  the  possible 
significance  of  certain  observed  force  configurations  or  event  sequences, 
(3)  focusing  collection  resources  on  higher  probability  areas  of  interest, 
and  (4)  systematically  building  confidence  at  an  early  stage  that  the 
enemy  option  and  point  in  the  option  have  been  determined. 
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Upon  determination  of  enemy  Intent,  the  G-2  next  develops  a  graphic 
estimate  of  the  situation  { 1 . e . ,  predicted  enemy  force  configuration 
fitted  to  terrain)  uslnq  IPS  products  as  a  basis.  G-3  functions  can 
Intensify  their  assessment  and  reaction  planning  at  that  point,  con¬ 
trasting  achievable  alternatives  for  the  commander's  review  and  decision. 
As  indicated  in  the  illustration,  IPB  product  use  during  hostilities  is 
largely  by  G-2  in  the  early  stages,  phaslnq  toward  heavy  use  by  G-3 
functions  as  real  time  battle  planning  commences. 

The  need  to  update  IPB  products  during  normal  planning  phases 
after  hostilities  commence  is  also  Indicated.  The  degree  of  thorough¬ 
ness  in  enemy  templatinq  will  vary  with  the  battle  situation,  but 
automation  tools  such  as  are  prescribed  in  this  document  make  it 
feasible  for  the  IPB  process  to  be  useful  throughout  the  battle, 
not  just  prior  to  the  initial  conflict. 

IPB  Functions 


The  automated  IPB  software  functions  that  support  the  operational 
concepts  are  shown  in  Figure  3-3.  They  are  composed  of  tv/o  principal 
categories: 

1.  IPB  application  functions 

2.  ADP  system  functions 

The  IPB  application  functions  represent  the  user  oriented,  IPB 
functional  requirements,  and  are  described  in  Section  3.1.  The  system 
functions  represent  the  ADP  oriented  functional  requirements,  which 
support  the  application  functions,  and  are  described  In  Section  3.2. 
Overall  system  performance/capacity  requirements  are  presented  In 
Section  3.3. 
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System  Functions 


Figure  3-3.  Automated  IPB  Software  Functions 


IPB  ADP  Configuration 

The  ADP  system  conf Iquratlon  that  will  support  the  IPB  functions 
is  shown  in  Figure  3-4.  The  principal  IPB  elements  in  the  configura¬ 
tion  are  the  IPB  analyst  positions  in  the  ASAC  and  the  ASAS  computer. 
IPB  interfaces  with  other  mutually  interactive  ASAC  and  TOC  functions 
are  also  shown. 

The  IPB  analyst  position  Is  supported  by  the  following  ADP: 

1.  Color  Graplcs  CRT  terminal  including  alphanumeric  keyboard 
function  keyboard,  and  cursor  controller. 

2.  Alphanumeric  CRT  terminal  including  alphanumeric  keyboard 

3.  Color  Graphics  monitor  for  display  of  the  current  situation 

4.  Graphics  data  tablet 

5.  Color  Graphics  hard  copy. 

Both  the  color  graohics  and  the  alphanumeric  CRT  terminals  require  the 
full  range  of  Interactive  capability.  The  color  qraphics  monitor  is 
one  of  an  assumed  internal  network  of  video  monitors  for  display  of  the 
current  situation.  It  would  not  have  the  interactive  capabilities 
ascribed  to  the  IPB  terminals.  The  graphics  data  tablet  is  included 
for  the  following  Intended  uses: 

1.  To  enter  graphic  data  (probably  map  related  but  not 
necessarily)  by  manually  tracinq  lines/contours  on  the 
Input  data  (drawing  or  map)  registered  In  position  on 
the  tablet. 

2.  lo  correlate  a  display  screen  position  to  a  map  position 
through  use  of  the  tablet  cursor  and  a  map  registered  on 
the  tablet. 
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Figure  3-4.  I PB  ADP  System  Configuration 


The  intended  use  of  the  color  graphics  hard  copy  is  to  provide  a 
flexible  and  cost  effective  means  to  distribute  IPB  graphic  products. 

The  ASAS  computer  will  provide  ADP  support  to  all  the  ASAC  functions, 
including  IPB,  and  will  be  composed  of  the  main  processor,  main  storage, 
and  input/output  controllers.  The  local  ADP  peripherals  required  for  IPB 
will  include  disks,  magnetic  tapes,  online  printer,  and  an  ADP  operator's 
system  console.  The  IPB  oriented  data  base  will  contain  enemy  and 
friendly  situation  data,  IPB  situation  independent  data  (maps,  terrain, 
weather,  doctrinal  templates),  and  situation  dependent  data  (snapshots, 
situation  templates,  event  templates). 

The  IPB  analyst  will  Interact  with  the  following  ASAC  functions: 

1.  Current  Situation  Maintenance  -  This  interface  provides  the 
IPB  analyst  with  graphic  updates  of  the  current  situation. 

2.  Collection  Management  -  This  Interface  provides  the  IPB 
analyst  the  means  to  specify  and  prioritize  intelligence 
data  needs  critical  to  the  IPB  process. 

3.  Target  Development  -  This  Interface  affords  the  IPB  analyst 
the  means  to  provide  IPB  products  that  could  support  target 
development,  as  well  as  coordinate  development  of  IPB  pro¬ 
ducts  to  ensure  that  targeting  considerations  are  incorporated. 

The  IPB  analyst  will  also  Interface  with  the  following  TOC 
functions: 

1.  Current  Situation  Assessment 

2 .  Maneuvers 

3.  Fires 


These  interfaces  are  required  during  both  the  preparation  and  planning 
phase  of  IPB  product  development,  and  the  more  time  critical  utiliza¬ 
tion  of  the  IPB  products  during  hostilities.  These  interfaces  will 
require  exchange  of  graphics  to  assure  a  common  perception  of  the 
tactical  and  analytical  situations.  Interfaces  are  also  shown  that 
will  provide  for  update  and  query  of  the  data  base. 


3.1  IPB  APPLICATION  SOFTWARE  FUNCTIONS 

3.1.1  IPB(A)  Source  Data  Requirements  and  Data  Entry  Functions 

This  section  will  describe  the  basic  data  inputs  required  to  allow 
automated  IPB  functions  to  begin  operations.  It  will  specify  the  form 
and  content  of  the  data  to  be  provided  for  input  to  the  ASAS  data  base 
and  subsequent  use  by  IPB  analysts.  Five  general  categories  of  input 
data  are  addressed: 

Map  data 
Terrain  data 
Weather  data 
Doctrinal  data 
Current  Situation  data 

3. 1.1.1  Lines  of  Communication  (LOC)  Man  Data 
LOC  map  data  shall  be  supplied  as  follows: 

a.  magnetic  tape  storage 

b.  UTM/?1GR  system  coordinates 

c.  sixteen  bit  words 
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d.  vector  format  with  alphanumeric  annotation  keyed 
to  location 

e.  map  reference  data  accessible  for  display  on  an 
alphanumeric  device 

The  vector  data  shall  be  divided  into  at  least  six  cateoories  and 
each  category  shall  consist  of  one  or  more  classes  as  indicated  in  the 
following  table: 


CATEGORY 

CLASS 

Roads 

Interstate/Autobahns,  Primary,  Secondary, 
Connecting 

Streams 

At  least  three  as  a  function  of  fording 
and  brldning  requirement 

Railroads 

TBD 

Airfields 

TBD 

Bridges 

5  classes  of  bridge  width 

Town  Boundaries 

One 

A/N  Annotation 

One 

Each  vector  "Category"  shall  be  separately  identifiable  so  that 
when  entered  into  the  IPB  system  it  is  addressable  by  a  graphic  display 
function  key/cursor  combination.  Further,  elements  within  each  Class 
in  a  given  Category  shall  be  entered,  to  the  extent  possible,  as  single 
vector  elements  so  that  they  can  be  changed,  modified  or  deleted  as  singl 
entries  by  the  operator. 


In  addition  to  the  vector  data  for  depicting  the  line  maps  on  the 
graphic  display,  map  reference  data  shall  be  supplied  in  alphanumeric 
form  by  category  and  coordinate.  This  is  included  so  that  the  analyst 
can  get  more  detailed  data  about  specific  graphically  displayed  items 
through  the  A/fl  display.  This  shall  be  accomplished  by  cursor  identi¬ 
fication  of  the  graphically  displayed  element  in  conjunction  with  a 
function  key  to  query  the  data  base. 

This  map  reference  A/N  data  shall  include  but  not  be  limited  to: 

•  Railroads  -  Name,  gauge,  capability  (trains  per  day 
per  direction,  etc.),  electrified  or  not 

•  Bridges/Tunnels  -  Name,  length,  width,  hi qhway/ rail  road, 
type,  load  bearing  capacity,  etc. 

•  Roads  -  Route  number/name,  class,  capacity,  construction 
type,  etc. 

•  Inland  Hydrography  -  Name,  width  (bank  to  bank),  depth  as 
a  function  of  month,  velocity  as  a  function  of  month,  bank 
height,  bank  slope,  stream  bottom  material  at  500  meter 
intervals. 

a  Airfield  -  flame,  civilian/military,  runway  length,  number 
of  runways. 

Two  sets  of  map  data  are  required:  1:250,000  scale  and  1:50,000 
scale.  In  addition,  1:1,000,000  scale  maps  shall  be  provided  in  hard 
copy  form  to  serve  as  indexes.  These  maps  shall  include  (in  addition 
to  standard  map  data  for  that  scale)  grids  that  associate  magnetic 
tape  library  numbers  with  geographic  areas,  referencing  these  to  paper 
copy  map  sheet  numbers. 
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Some  generalization  of  the  hard  copy  1:250,000  and  1:50,000  maps 
shall  be  accomplished  during  their  digitization.  This  generalization 
shall  be  attained  by  reducing  the  number  of  vectors  of  all  classes  of 
all  categories  by  a  factor  of  5  to  10  compared  to  the  paper  map  sheets. 

The  results  of  such  a  reduction  is  shown  in  Figure  3. 1.1-1,  an  example 
of  a  graphically  displayed  1:50,000  digitized  map.  The  map  includes 
an  area  15  kilometers  by  20  kilometers  and  four  categories  of  data: 
roads,  streams,  bridges,  and  town  boundaries.  Three  classes  of  roads 
are  depicted  by  three  colors  (white,  green,  yellow);  two  classes  of 
bridges  (white  and  yellow);  three  classes  of  streams  (cyan,  blue, 
magenta).  The  railroads,  airfields  and  A/N  annotation  categories  have 
been  deleted.  Tick  marks  and  grid  labels  are  not  shown  since  these  are 
not  part  of  the  source  data;  rather,  they  shall  be  internally  generated 
by  the  graphics  system.  The  total  vector  word  count  for  such  a  graphic 
but  including  tick  marks,  grid  labels  and  annotation  is  less  than  2,000. 

3. 1.1. 2  Terrain  Data 

The  IPB/TIAX  Final  Report  Phase  A  detailed  how  terrain  subfactor 
data  (slope,  soils,  vegetation)  currently  developed  for  manual  use  in 
acetate  overlay  form  can  be  converted  to  the  IPB(A)  five-part  mobility 
scale.  To  support  the  IPB  processes  the  level  of  detail  of  terrain  data 
is  generally  less  than  that  required  for  most  military  applications. 

This  is  due  primarily  to  the  simplified  use  of  five-part  mobility  scale 
and  three-part  intervisibility  scale,  and  the  use  of  500  meter  resolution. 
These  simplifications  significantly  reduce  the  data  collection,  terrain 
analysis,  and  terrain  data  storage  requirements  for  the  IPB  process. 

The  discussion  that  follows  describes  the  terrain  data  requirements 
required  to  support  IPB  using  the  five-part  mobility  and  intervisibility 
scales.  The  five-part  scale  represents  a  new  method  of  describing  basic 
terrain  data  in  terms  of  its  effect  on  mobility  and  intervisibility. 


Figure  3.1. 1-1  1:50,000  Folger  Lines  of  Communication 


In  order  to  relate  these  new  definitions  to  more  conventional  (and 
detailed  terrain  data)  additional  tables  are  provided  describing  the 
relationship  between  the  more  conventional  data  and  the  IPB  method 
of  terrain  data  representation  (see  Appendix  E).  It  should  be  noted, 
however,  that  for  IPB  only  key  conventional  terrain  data  discriminants 
need  to  be  collected  and  analyzed. 

Six  categories  of  terrain  data  shall  be  required  for  the  automated 
IPB  system:  terrain  elevation,  surface  configurations,  vegetation, 
soils,  wetlands,  and  built-up  areas.  The  following  data  shall  be 
supplied  on  magnetic  tape  for  each  500  meter  square: 


Number  of 


Characters  Per  Square 


4 

1 

1 

1 


1 

1 

1 

4 

1 

J_ 

Total  16 


Coordinates 

Soil -Mobility  (5  tyDes) 

Surface  Configuration-Mobility  (5  types) 

Surface  Configuration- Intervisibility 
(3  types) 

Vegetation-Mobility  (5  types) 
Vegetation-Intervisibility  (3  types) 
Vegetation-Tree  Heights  (4  types) 
Elevation-Intervisibil ity 
Built-Up  Areas  (2  types) 

Wetland  Areas  (5  types) 


Terrain  data  shall  be  digitized  to  500  meter  x  500  meter  squares  center- 
to-center.  The  UTM/MGR  coordinate  origins  used  shall  be  common  to  all 
maps  and  L0C  data. 
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Rivers  and  streams  whose  widths  are  less  than  500  meters  are 
presented  as  linear  vector  data  which  is  added  to  the  area  wetlands 
to  form  a  composite  wetlands  overlay. 

Figure  3. 1.1-2  identifies  the  several  types  of  data  required  within 
a  given  category.  The  upper  portion  of  the  chart  deals  with  vegetation, 
surface  configuration,  soils  data,  and  wetlands  in  terms  of  impact  on 
ground  force  mobility.  Each  category  is  broken  down  into  the  IPB(A) 
five-part  mobility  scale;  also  shown  are  the  equivalent  conventional 
data  types  used  by  the  U.S.  Army  Engineering  Topographic  Lab  (ETL). 

The  lower  portion  of  the  chart  indicates  the  vegetation  and  surface 
configuration  data  required  to  support  IPB(A)  intervisibility  require¬ 
ments.  The  3-part  intervisibility  scale  is  shown  down  the  left  side  of 
the  chart.  The  section  "Other  Requirements"  rounds  out  the  definition 
of  terrain  source  data  requirements  for  areas  where  terrain  analysis 
data  does  not  exist  in  conventional  form. 

Figure  3. 1.1 -3  is  an  example  of  a  surface  configuration  (slope) 
overlay  on  a  map  background  at  1:50,000  scale  as  it  would  appear  on  the 
CRT.  Slope  data  (only)  is  represented  in  terms  of  its  impact  on  ground 
force  mobility.  In  the  example,  each  block  represents  500  meters  by 
500  meters.  The  color  coding  is  red  *  stop,  magenta  =  very  slow, 
yellow  *  slow,  cyan  *  inhibited  and  green  =  go.  This  representation 
is  built  from  the  characters  pertaining  to  mobility  within  the  basic 
16-character  data  block  per  500  meter  square. 
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IPB( A)  TERRAIN  DATA  REQUIREMENTS  FOR  MOBILITY  AMO  INTERVISIBILITT 


Figure  3. 1.1-2.  IPB(A)  Terrain  Data  Requirements  for  Mobility  and  Intervisibility 
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Figure  3.1. 1-3  1:50,000  Polger  Map  and  Slope 


With  the  data  coded  In  this  fashion  the  following  types  of  overlays 
can  be  displayed  by  the  IPB  analyst: 

•  Surface  Configuration  (slope) 

•  Vegetation 

•  Soils 

0  Wetlands 

•  Built-Up  Areas 

•  Intervisibility 

•  Crosscountry  Matrix 

3. 1.1. 3  Weather  Data 

Two  types  of  weather  data  shall  be  required  to  support  the  IPB 
process: 

•  Daily  forecast  reports 

•  Climatic  data 

The  daily  forecast  reports  shall  be  provided  as  hard  copy  products 
consisting  of  alphanumeric  and  facsimile  data.  The  alphanumeric  data 
shall  be  supplied  as  normal  12  hours,  24  hours,  etc.,  forecast,  weather 
observations,  weather  warninqs,  etc.,  teletype  data.  This  data  shall 
be  used  to  Initialize  the  IPB  system,  as  discussed  in  paragraph  3. 1.2.1 
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for  the  region(s)  of  interest.  It  is  used  by  the  operator  to  inter¬ 
actively  update  terrain  subfactor  and  LOC  data.  The  facsimile  data 
consists  of  graphic  weather  map  data  and  shall  include  a  crude  map, 
location  and  type  of  weather  activity,  direction  of  movement,  cloud 
cover,  temperature  and  precipitation.  It  shall  be  supplied  through 
conventional  weather  facsimile  devices  and  shall  be  manually  input 
into  the  IPB  system  through  the  graphic  tablet  and  A/N  terminal. 

Figure  3. 1.1 -4  is  an  example  of  the  resulting  weather  overlay  as 
stored  in  the  IPB  analyst  files.  A  primary  use  of  this  weather  over¬ 
lay  is  as  an  aid  for  correlating  the  weather  situation  with  the  analyst 
area  of  interest. 

As  an  example  of  climatic  data,  fog  data  would  be  stored  as 
vectors  on  magnetic  tape  for  input  into  the  IPB  system.  It  shall  be 
logged  on  the  tape  as  a  function  of  location  (UTM/MGR  coordinate)  and 
expected  time  of  occurrence  (month  of  year,  time  of  day--AM/PM).  The 
data  is  prestored  on  the  basis  that  certain  areas  of  the  world  are 
predictably  conducive  to  recurring  morning/ evening  ground  fog. 

Figure  3. 1.1-5  is  an  example  of  such  a  predicted  fog  layer  which  is 
expected  to  exist  in  the  confines  of  the  high  river  banks  of  the 
Granbury  region.  In  addition  to  fog  data  the  IPB  system  shall  have 
the  capability  to  receive/store  other  types  of  climatic  information 
represented  graphically  for  use  with  background  maps. 

3. 1.1.4  Doctrinal  Data 

Doctrinal  data  on  enemy  forces  are  used  to  represent  a  number  of 
options  and  courses  of  action  Including: 

Movement  to  Contact 

Meeting  Engagement 

Quick  Attack 
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Figure  3. 1.1-5  Fog  Overlay  on  Map 


Deliberate  Attack 

Pursuit 

Hasty  Defense 

Deliberate  Defense 

Retrograde 

Withdrawal 

Assault  River  Crossing 
Amphibious  Operations 
Airborne  Assault 

Doctrinal  data  required  for  IPB  shall  Include  the  following 
categories  of  templates: 

1.  Doctrinal  Option  Template 

A  graphic  showing  one  of  several  alternative  enemy  battle 
plans  based  on  doctrine  without  consideration  of  terrain 
or  weather  factors.  It  generally  portrays  maneuvers  by  the 
higher  echelons,  i.e.,  regimental  or  division  sized  units. 
It  covers  the  period  from  commencement  of  a  major  action  to 
the  achievement  of  a  major  objective. 

2.  Doctrinal  Template 

A  graphic  showing  composition  and  disposition  of  an  enemy 
unit  based  on  doctrine  without  consideration  of  terrain 
and  weather  factors.  It  can  be  constructed  for  various 
types  of  units  at  any  echelon.  It  will  vary  depending 
on  enemy  mission. 
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3. 


Doctrinal  Event  Menus 


Tabular  listings  of  critical  events/indicators  which  are 
characteristic  of  enemy  operations  and  maneuvers  and  can 
be  related  to  particular  phases  of  an  enemy  option  sequence. 
They  are  prepared  separately  for  each  option /maneuver  type 
and  reflect  enemy  doctrine  without  consideration  of  terrain 
and  weather. 

4.  Doctrinal  Target  Menus 

Tabular  listings  of  targets/tarqet  areas.  Target  Menus  are 
similar  in  concept  to  the  Doctrinal  Event  Menus.  They  repre¬ 
sent  planned  targets  based  on  doctrine  without  consideration 
of  terrain  and  weather.  They  represent  key  targets/target 
areas  which  if  Interdicted  by  friendly  fires  action  can 
produce  a  slowing  or  deterrence  of  the  enemy's  option 
execution. 

Each  of  the  four  categories  of  doctrinal  data  are  discussed  in 
the  paragraphs  which  follow.  Descriptions  of  their  content  are  pro¬ 
vided.  The  forms  required  for  input  to  the  IPB  automated  system  are 
given. 

3. 1.1. 4.1  Doctrinal  Option  Templates 

IPB  requires  the  graphic  portrayal  of  all  types  of  friendly  and 
enemy  operations,  offensive  and  defensive.  Each  option  template  should 
depict  a  basic  form  or  category  of  troop  maneuver;  e.q.,  envelooment. 

All  variations  of  a  basic  maneuver  should  be  covered  separately,  i.e., 
single  envelopment  separately  from  double  envelopment.  Generally,  these 
templates  portray  maneuvers  by  division  or  higher  echelon  forces. 
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Content 


Each  option  template  shall  Include  the  identification  of  the  enemy 
or  friendly  nation  and  the  option  portrayed.  It  shall  be  developed  at 
a  scale  of  either  1:250,000  or  1:50,000,  and  the  scale  used  must  be 
Indicated.  All  significant  dimensions  are  to  be  labeled.  All  symbols 
shall  be  in  accordance  with  the  standard  symbol  set,  i.e.,  FM  21-30. 

The  focal  point  shall  be  identified,  that  is,  the  point  or  line  from 
which  most  dimensions/distances  are  measured  such  as  the  Line  of 
Contact.  Significant  items  which  should  be  depicted  include: 

Objectives 

Depths 

Areas 

Zones 

Frontages 

Lines  of  Coordination 
Lines  of  Control 
Phase  Lines 
Line  of  Contact 

First  and  Second  Echelon  Forces 
Direction  of  Movement 

Each  template  shall  be  given  a  name/title  and  marked  with  the  date  of 
preparation,  agency/office  preparing,  scale  to  which  drawn,  and  a 
brief  descriptive  phrase.  Figure  3. 1.1-6  is  an  example  of  a  doctrinal 
option  template  portraying  an  enemy  double  envelopment  option  at  a 
1:250,000  scale. 
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Figure  3. 1.1-6.  Double  Envelopment  Option  Doctrinal  Template 
Division  Size  Forces  in  Each  Attack 


Format 


These  templates  should  be  sketches  or  diagrams  drawn  to  scale. 

Lines  and  symbols  are  to  be  drawn  as  they  are  to  be  seen  on  the  graphics 
terminal.  Any  item  which  is  to  be  in  a  specific  color  and/or  blinking 
on  the  graphics  terminal  must  be  so  marked  on  the  template.  For  those 
templates  drawn  at  a  1:250,000  scale,  tick  marks  denotinq  10  kilometers 
should  be  included,  and  for  1:50,000  scale  tick  marks  denoting  each 
2  kilometers.  An  origin  point  should  be  labeled.  The  origin  is  the 
point  used  by  the  system  to  locate  and  orient  the  template  on  the  screen. 
It  must  be  visible  so  the  operator  can  use  it  in  conjunction  with  the 
cursor  to  manipulate  the  template  on  the  screen,  or  to  delete  it. 

Data  Form/Mode 


These  templates  should  be  issued  on  magnetic  tape  in  a  file  which 
conforms  to  the  system  data  base  conventions.  Each  record  in  the  file 
will  contain  the  name/title,  type  of  doctrinal  template,  originating 
agency/office,  date  prepared,  scale,  brief  description  and  the  qraphic 
imagery  itself. 

A  less  desirable  but  adequate  form  would  be  to  issue  the  template 
drawn  on  84  x  11  paper. 

3. 1.1. 4. 2  Doctrinal  Templates 

These  templates  are  used  to  graphically  represent  enemy  unit 
composition  and  disposition  in  each  option  and  course  of  action 
previously  Itemized.  They  are  prepared  to  reflect  doctrine  without 
consideration  of  terrain  and  weather  factors.  Generally  the  templates 
shall  depict  maneuver  and  fire  units  from  division  through  the  battalion 
echelon.  Special  and  non-organic  units  (assigned  from  an  Army  or  higher 


3-29 


echelon)  shall  be  incorDorated  into  division  and/or  regimental  templates 
and  will  be  called  division  slice  or  regimental  slice  templates. 

Content 

Doctrinal  templates  shall  be  drawn  to  scale.  The  preferred  scale 
for  division  templates  is  1:250,000.  The  preferred  scale  for  regiment 
and  battalion  templates  is  1:50,000.  All  significant  dimensions  shall 
be  labeled.  Templates  shall  be  constructed  using  standard  military 
symbols.  Templates  shall  depict  significant  military  data  including 
line-of-contact,  phase  lines,  coordination  lines,  frontages,  depths, 
direction  of  movement  and  unit  boundaries. 

A  sample  template  for  a  motorized  rifle  regiment  in  a  movement  to 
contact  is  shown  in  Figure  3. 1.1-7.  Figure  3. 1.1-8  is  a  sample  for  a 
motorized  rifle  regiment  in  a  breakthrouqh  attack. 

Format 

These  templates  should  be  sketches  or  diagrams  drawn  to  scale. 

Lines  and  symbols  are  to  be  drawn  as  they  are  to  be  seen  cn  the  graphics 
terminal.  Any  item  which  is  to  be  in  a  specific  color  and/or  blinking 
on  the  graphics  terminal  must  be  so  marked  on  the  template.  For  those 
templates  drawn  at  a  1:250,000  scale,  tick  marks  denoting  10  kilometers 
should  be  Included,  and  for  1:50,000  scale,  tick  marks  denoting  each 
2  kilometers.  An  origin  point  should  be  labeled.  The  origin  is  the 
point  used  by  the  system  to  locate  and  orient  the  template  on  the  screen. 
It  must  be  visible  so  the  operator  can  use  it  in  conjunction  with  the 
cursor  to  manipulate  the  template  on  the  screen,  or  to  delete  it. 
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Note:  Final  tamplata  tor  Input 
to  IPB(A)  system  shall  ba 


Doctrinal  Template  -  Motorized  Rifle  Regiment  in  Movement  to  Contact 


Doctrinal  Template  -  Motorized  Rifle  Regiment 
in  a  Breakthrough  Attack 


Data  Form/Mode 


These  templates  should  be  Issued  on  magnetic  tape  In  a  file  which 
conforms  to  the  system  data  base  conventions.  Each  record  In  the  file 
will  contain  the  name/title,  type  of  doctrinal  template,  originating 
agency/office,  date  prepared,  scale,  brief  description  and  the  graphic 
imagery  itself. 

A  less  desirable  but  adequate  form  would  be  to  issue  the  template 
drawn  on  8*s  x  11  paper. 


3. 1.1. 4. 3  Doctrinal  Templates  -  Event  Menus 

Event  menus  are  lists  of  detectable  events  which  are  characteristic 
of  enemy  operations/military  maneuvers.  They  can  be  prepared  from 
descriptions  of  enemy  doctrine.  These  menus  are  used  to  prompt  the  IPB 
Analyst  when  he  is  preparing  the  Event  Matrix  and  to  speed  his  finali¬ 
zation  of  the  matrix  by  saving  key  strokes.  Event  menus  should  be 
prepared  for  the  types  of  operations  that  are  expected  to  be  encountered, 
for  example: 

March  to  Contact 
Meeting  Engagement 
Quick  Attack 
Deliberate  Attack 
Pursuit 
Hasty  Defense 
Deliberate  Defense 
Withdrawal 
Airborne  Assault 
Assault  River  Crossings 
Amphibious  Operations 
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Events  reflecting  combat  support  and  combat  service  support  operations 
supporting  the  main  maneuver  or  special  operation  should  be  included  in 
the  menu.  The  criteria  for  including  an  event  in  the  doctrinal  menu 
are  (1)  Is  it  detectable?  and  (2)  Is  it  an  indicator?. 

Content 


Each  menu  should  contain  its  title,  the  event  name  of  each  event 
and  a  brief  description  of  that  event,  leaving  blank  spaces  where 
location  or  other  specific  Information  might  logically  be  added  when 
the  menu  is  applied  in  a  given  situation.  Figure  3. 1.1-9  is  an 
example  of  an  Event  Menu  for  Assault  River  Crossings. 

In  addition,  each  menu  should  contain  a  short  name/title,  origi¬ 
nating  agency/office,  date  prepared,  nationality  of  the  enemy  to  which 
applicable,  and  type  of  doctrinal  template. 

Format 


The  menu  is  an  alphanumeric  columnar  format  which  can  be  read  on 
the  A/N  CRT  screen.  The  lengths  of  the  fields  of  data  are  disciplined 
by  the  conventions  of  the  CRT  and  the  data  base  system.  All  of  the 
menus  will  be  contained  in  a  file  and  Figure  3. 1.1 -9  represents  an 
output  product  from  the  file.  The  top  line  is  the  title.  Multipage 
menus  are  handled  by  page  numbering  (line  2).  Columnar  headings  include 
the  means  to  select  a  specific  event.  The  Event  Name  is  abbreviated  so 
as  to  fit  within  the  field  size.  The  Event  Description  may  also  contain 
readily  understood  abbreviations  and  blank  spaces  for  additional 
specific  data. 
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DOCTRINAL  EVENT  MENU  FOR  RIVER  CROSSING 
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Figure  3. 1.1-9.  River  Crossing  Doctrinal  Event  Menu  Example 


Data  Form/Mode 


These  menus  should  be  issued  on  magnetic  tape  in  a  file  which 
conforms  to  the  system  data  base  conventions.  Each  record  in  the  file 
will  be  identified  by  the  short  name/title  of  the  event  menu. 

A  less  desirable  but  adequate  form  would  be  to  issue  the  menu  on 
punched  cards. 

3. 1.1. 4. 4  Doctrinal  Target  Menus 


Doctrinal  target  menus  are  lists  of  potential  targets  which  are 
inherent  to  a  specific  type  of  energy  unit  and  the  kind  of  activity  or 
operation  in  which  that  unit  is  engaged.  They  are  prepared  from 
descriptions  of  enemy  doctrine,  knowledge  of  energy  TO&E  and  equipment 
characteristics.  They  are  closely  related  to  doctrinal  templates. 
Doctrinal  target  menus  are  used  to  prompt  the  IPB  analyst  when  he  is 
preparing  the  Target  Analysis  Matrix.  They  are  designed  to  foster 
standardization  and  to  save  excessive  key  strokes  in  preparing  the 
target  analysis  matrix.  Menus  shall  be  prepared  for  each  combination 
of  enemy  unit  type  and  military  operation  expected  to  be  encountered, 
for  example.  Tank  Battalion  in  Deliberate  Attack,  or  Tank  Battalion  in 
Water  Obstacle  Crossing. 

The  criteria  for  including  potential  targets  are:  (1)  Is  it 
detectable?  and  (2)  Is  it  vital/important  to  the  energy's  success,  i.e., 
a  critical  node?  A  target  Is  defined  to  be  anything  the  commander  may 
want  to  shoot  at.  Intercept  or  jam. 
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Content 


Each  menu  should  contain  a  title,  the  types  of  targets,  brief 
descriptions  of  the  targets  and  Indications  of  the  permanence  of  the 
targets.  Examples  of  types  of  targets  are:  emitter,  shooter,  mover, 
area,  or  Interdiction.  Examples  of  target  descriptions  are: 

•  CP 

•  Artillery  batteries 

•  SAM  radar/ SAM 

•  Target  acquisition  radar 

•  MET  radar 

•  Fire  control  radar 

•  Rocket/Mlsslle  position 

•  VHF  radio 

•  DF  equipment 

•  Troop  concentration 

•  Supply  dump 

•  CSS  trains 

Permanence  describes  the  relative  time  the  target  Is  expected  to  be 
stationary.  Permanence  may  be  expressed  as: 

•  Moving  (and  continuing  to  move) 

•  Moving  -  expected  to  stop 

•  Stationary  (and  continuing  to  be  stationary) 

•  Expected  to  move 

Figure  3.1.1-10  Is  an  example  of  a  Doctrinal  Target  Menu  for  a 
Motorized  Rifle  Regiment  In  the  Attack.  Figure  3. 1.1-8  was  used  In 
conjunction  with  enemy  doctrine  and  types  of  equipment  associated  with 
the  subordinate  units.  Note  that  the  menu  lists  a  certain  target  type 
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only  once  although  It  may  be  used  several  times  on  a  target  analysis 
matrix.  Thus  the  first  entry  In  the  menu  is  the  regimental  CP  even 
though  the  target  analysis  matrix  may  Include  the  Forward,  the  Main 
and  the  Rear  CPs.  The  column  on  the  right  labeled  "Select"  provides 
the  means  by  which  the  IPB  analyst  can  select  target  Items  for  auto¬ 
matic  Inclusion  in  the  target  analysis  matrix. 

In  addition,  each  menu  should  contain  a  short  title/name,  orlgl- 
.  nating  agency /off ice,  date  prepared,  nationality  of  the  enemy  to  which 
1  applicable  and  the  type  of  template. 

Format 


The  target  menu  Is  alphanumeric  In  format  and  Is  used  on  the  A/N 
CRT  screen  In  columnar  format.  The  menus  are  contained  In  a  file  In  a 
format  compatible  with  the  data  base  management  system.  Understandable 
abbreviations  are  permlssable.  Lengths  of  fields  of  data  are  disciplined 
by  the  conventions  of  the  data  base  system.  Constraints  imposed  on 
lengths  by  the  CRT  size  may  be  overcome  by  using  more  than  one  line  to 
display  the  contents  of  a  data  field.  Figure  3.1.1-10  represents  an 
output  product  of  the  file  rather  than  the  precise  format  required  of 
the  data  source. 

Data  Form/Mode 


These  menus  should  be  Issued  on  magnetic  tape  In  a  format  amenable 
to  entry  Into  the  system  data  base.  Each  record  In  the  file  will  be 
Identified  by  tne  short  name/title  of  the  event  menu. 

A  less  desirable  but  adequate  form  would  be  to  Issue  the  menu  on 
punched  can's. 
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3. 1.1. 5  Current  Situation  Data  Requirements/ Assumptions 


Current  Situation  data  Is  required  for  both  enemy  and  friendly 
forces  In  order  to  support  the  IPB(A)  function.  In  a  fielded  ASAS,  It 
Is  assumed  that  both  the  graphic  and  tabular  current  situation  data 
would  be  continuously  monitored  and  updated  and  would  be  available  In 
a  timely  manner  to  the  IPB(A)  analyst. 

The  following  paragraphs  state  general  requirements  which  the  IPB(A) 
function  places  on  the  ASAS  maintained  current  situation  capability. 

A  detailed  description  of  content  and  formats  Is  not  attempted  at 
this  time  based  on  the  fact  that  the  Army  Is  about  to  commence  a 
major  ASAS  design  study  which  It  Is  assumed  will  develop  these 
specifications. 

General  Content 

The  current  situation  data  base  shall  contain  order  of  battle  type 
factors  (for  example  unit  name,  type,  strength,  composition  and  dis¬ 
position)  which  In  general  shall  permit  graphic  representation  of  forces 
on  map  backgrounds.  The  data  base  content  and  organization  shall  also 
permit  response  to  tabular  queries. 

Data  Manipulation  and  Display 

It  Is  assumed  that  an  ASAS  function  (not  IPB(A))  shall  maintain/ 
update  a  CRT  graphic  monitor  referred  to  herein  as  the  current  situation 
master  monitor  or  display.  At  the  IPB(A)  station,  the  IPB(A)  analyst 
must  be  able  to: 

1.  Access  the  master  current  situation  update  onto  his  slaved 
monitor. 
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2.  Focus  on  certain  areas  of  the  current  situation  display  and 
offset  and  rescale  his  current  situation  monitor.  It  shall 
be  possible  to  modify  the  scale  of  the  slaved  display  without 
interrupting  or  disrupting  the  master  display. 

3.  Access  all  or  part  of  the  master  current  situation  update 
onto  his  IPB  graphic  screen.  For  example,  he  shall  be  able 

to  display  blue  force  only,  red  force  only,  blue/red  artillery 
units  only,  forces  of  regimental  or  higher  echelon  only,  etc. 

4.  Access  current  situation  graphics  onto  his  IPB  graphic 
screen.  Initialize  a  cursor  identified  query  about  it 
and  have  results  automatically  displayed  on  his  tabular 
screen. 

Figures  3.1.1-11  and  3.1.1-12  are  samples  of  the  form  in  which  it 
is  assumed  the  current  situation  will  be  provided. 

3.1.2  IPB  Product  Build  Function 

Figure  3. 1.2-1  Is  an  overview  of  the  process  the  IPB  analyst  uses 
to  build  automated  IPB  products  for  subsequent  use  by  G-2/G-3  staff 
personnel . 

The  source  data  Items  under  Inputs  would  be  developed  by  support 
agencies  and  "provisioned"  In  appropriate  sets  to  units  In  the  field. 

They  have  the  common  attribute  of  being  situation  independent;  their 
preparation  requires  application  by  specialists  of  considerable  technical 
Information.  They  could  be  modified  In  the  field,  but  the  basic  set 
would  be  provided  by  support  agencies.  Preceding  sections  described 

In  more  detail  the  source  data  requirements. 
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Figure  3.1.1-12  1:50,000  Expanded  Current  Situation 


Figure  3. 1,2-1.  Build  Process 


Inputs 


The  analyst  has  available  dt  ’  inal  descriptions  of  major  options 
employed  by  enemy  forces  to  achieve  their  objectives  in  various  military 
situations. 

Doctrinal  templates  of  enemy  forces  at  the  echelons  of  battalion 
and  higher  are  available.  They  provide  the  analyst  with  graphic  repre¬ 
sentations  of  high  Interest  force  elements  in  road  march,  pre-combat 
and  combat  formation. 

The  inputs  Include  digitized  terrain  information  which  defines 
Individual  and  combined  terrain  factors  (slope,  vegetation,  dry  and  wet 
soils,  and  crosscountry  mobility)  effects  on  armored  vehicle  mobility. 
Further  Information  is  Included  on  road  and  river  classifications  and 
their  effect  on  armored  vehicle  and  wheeled  vehicle  mobility. 

Map  backgrounds  for  graphic  screen  display  at  varying  scales  and 
levels  of  detail  are  available  In  the  IPB  data  base.  In  support  of 
these  graphic  data  sets,  the  IPB  data  bases  include  detailed  technical 
data  In  tabular  form.  Examples  are  detailed  technical  data  on  lines  of 
communications;  detailed  terrain  subfactor  characteristics,  and  detailed 
weather  effects  characteristics. 

Processing  Algorithms 

Processing  functions  are  available  to  the  analyst  in  the  IPB  soft¬ 
ware  programs.  These  allow  him  to  input  real  time  computation  parameters 
at  his  station  and  cause  the  system  to  immediately  compute  Information 
on  corridor  mobility  ratings,  force  movements  and  timings;  changes  to 
composite  mobility  ratings  caused  by  weather;  combat  power  ratios,  and 
Intervislblllty  corridor  ratings.  More  detailed  descriptions  of  the 
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special  automated  processes  and  analyst  aids  be  elsewhere  in  this 
document. 

Outputs 

Outputs  or  products  which  are  prepared  ahead  of  a  battle  and 
stored  for  real  time  use  by  the  analyst  are  shown  on  the  right  hand 
side  of  Figure  3. 1.2-1.  With  a  basic  set  of  maps,  terrain  data,  and 
doctrinal  templates,  operating  units  can  begin  development  of  the 
products  illustrated  under  Outputs  as  soon  as  they  have  a  specific 
military  situation  with  which  to  deal.  It  can  be  the  "current 
situation"  as  understood  prior  to  an  initial  attack  (or  during  the 
battle),  or  it  could  be  a  contingency  situation  for  which  operating 
plans  must  be  developed.  In  order  to  develop  the  basic  IPB  products 
illustrated,  there  must  be  an  enenjy  force  at  a  known  or  estimated 
location,  friendly  forces  having  a  mission  to  deal  with  the  enemy, 
and  hypothesized  enemy  objectives  and  options  for  achieving  these 
objectives.  With  these  ingredients,  the  IPB  process  can  begin  to 
function.  The  following  sections  describe  how  terrain  composite 
overlays  are  built  with  IPB  software,  how  weather  information  is 
used  In  this  process  to  affect  mobility  rating  and  how  the  IPB 
4-step  templates  are  built. 

3. 1.2.1  Weather  Data  Utilization 

The  IPB  analyst  shall  be  able  to  input  weather  forecast  data 
(Section  3. 1.1. 3)  into  the  system.  This  process  shall  occur  twice 
per  24  hours  on  the  average  and  shall  be  accomplished  through  operator 
Interaction  with  an  alphanumeric  display  and  light  pen.  With  the 
light  pen,  the  operator  shall  be  able  to  specify,  from  a  set  of  A/N 
menus,  the  appropriate  weather  condition  for  the  selected  area  of 
Interest  and  forecast  time  period.  The  result  of  this  process  will 


be  subfactor  overlays  or  composite  subfactor  overlays  (soils,  CCMs, 

COMs,  intervisibility*  etc.)  reflectinq  the  Integration  of  current 
weather  information  with  terrain  data  for  the  areas  of  interest. 

Five  menus  shall  be  required  (see  Figure  3. 1.2-2): 

•  Weather  Update  Menu  List 

•  Intervisibility  Overlay  Initialization  Menu 

•  Crosscountry  Mobility  (CCM)  Overlay  Initialization  Menu 

•  Line  of  Communication  (LOC)  Overlay  Initialization  Menu 

•  Combined  Obstacles  Matrix  Current  Weather  Update  Menu 

Figure  3. 1.2-3  shows  a  flow  of  operator/machine  functions  necessary 
to  input  weather  data.  Hard  copy  weather  forecasts  are  utilized  in 
addition  to  the  weather  overlay  to  determine  appropriate  weather 
parameters.  The  Weather  Update  Menu  List  is  called  up  on  the  A/N 
display.  The  analyst  also  calls  the  current  weather  map  on  the  graphic 
display.  Through  the  graphic  cursor,  the  operator  Inputs  the  coordinates 
for  the  area  of  interest  and  the  coordinates  appear  on  the  A/N  display. 
The  analyst  then  identifies  by  light  pen  the  box  associated  with  the 
overlay  to  be  updated  and  the  selected  menu  shall  appear.  This  menu 
shall  contain  the  time  and  date  of  the  last  update  and  the  parameters 
selected  for  that  last  update  shall  be  indicated  by  a  symbol  inside  the 
appropriate  boxes.  When  the  analyst  identifies  a  parameter  by  light  pen, 
time  and  date  are  automatically  updated.  Those  items  in  Figure  3. 1.2-2 
bounded  with  dashed  lines,  i.e.,  snow  depth  and  ice  thickness,  shall  not 
appear  unless/until  the  snow  covered  and/or  frozen  blocks  are  selected. 

The  effect  of  the  menu  inputs  is  to  select  appropriate  tables 
(see  Figure  3. 1.2-4)  for  modification  of  the  terrain  data  codes  to 
reflect  mobility  values  that  take  weather  conditions  into  account. 
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Figure  3. 1.2-2.  Weather  Update  Menus 
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Figure  3. 1.2-3.  Weather  UPdate  Flow 


Weather  Menus  Referenced  to  Factor  Tables 


The  numbers  outside  the  boxes  In  Figure  3. 1.2-4  are  reference 
numbers  to  specific  tables  contained  In  Appendix  C. 


3. 1.2. 2  Terrain  Composite  Overlays 

3. 1.2. 2.1  Combined  Obstacles  Matrix  (COM) 

A  combined  obstacles  matrix  of  an  area  Is  a  composite  of  the  lines 
of  communication  (LOCs)  and  the  crosscountry  movement  (CCM)  overlays  of 
the  area.  It  shall  present  the  characterization  of  the  crosscountry 
terrain  and  lines  of  communication  In  terms  of  the  IPB(A)  five  categories 
of  mobility.  An  example  of  a  COM  with  1:50,000  scale  detail  Is  shown  In 
Figure  3. 1.2-5.  Each  color  In  the  figure  conveys  relative  mobility  of 
military  ground  forces  across  the  terrain.  Since  weather,  season,  etc., 
shall  affect  both  CCMs  and  LOCs  they  will  normally  be  developed  on  an 
approximate  dally  basis  using  operator  Inputs  of  weather  Information 
In  conjunction  with  basic  terrain  data  to  form  composites. 

Crosscountry  Mobility  (CCM)  Overlay 

The  CCM  overlay  shall  be  a  composite  of  soils,  vegetation,  surface 
configuration  and  built-up  area  subfactor  effects.  The  subfactor  effects 
shall  be  automatically  compiled  according  to  the  method  discussed  In 
Section  3. 1.2.1  Weather  Data  Utilization. 


\ 
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Figure  3. 1.2-5  1:50,000  Folger  Combined  Obstacles  Matrix 


For  data  stored  In  ETL  format  or  IPB(A)  simplified  format,  the 
process  of  assembling  the  necessary  subfactor  data  into  a  composite 
overlay  reflecting  the  effect  of  all  terrain  subfactors  on  mobility 
is  Illustrated  in  Figure  3. 1.2-6.  The  method  of  converting  existing 
terrain  analysis  data  into  IPB(A)  subfactor  data  has  been  discussed 
In  detail  In  Section  5  of  TIAX  Phase  A  Final  Report. 

The  flow  of  man/machine  interactions  required  to  implement  the 
process  is  shown  In  Figure  3. 1.2-7  and  is  summarized  as  follows: 

•  Input  weather  effects  as  discussed  In  Section  3. 1.2.1.  Note 
that  it  is  not  necessary  to  perform  this  operation  if  weather 
conditions  have  not  changed  since  the  last  update. 

•  The  analyst,  through  the  graphic  terminal,  selects  the  area 
of  Interest  and  the  function  to  be  performed,  e.g.,  display 
CCM  for  selected  area. 

•  The  IPB  analyst  shall  be  aware  (through  reconnaissance,  etc.), 
of  the  currency  of  the  terrain  subfactor  data  (soils,  vegeta¬ 
tion,  slopes,  built-up  areas)  used  to  make  a  CCM.  If,  In  his 
judgment  any  of  this  data  lacks  validity,  due  to  engineering, 
military  or  other  effects,  he  shall  modify  the  data  through 
the  graphics  terminal  as  required. 

•  The  computer  shall  translate  the  stored  terrain  code  to  appro¬ 
priate  IPB(A)  mobility  factors  using  the  automatically  selected 
tables. 

•  The  computer  shall  multiply  the  Surface  Configuration  mobility 
factor  times  the  Vegetation  mobility  factor  times  the  Soils 
mobility  factor  times  the  Built-Up  Areas  mobility  factor. 
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Figure  3. 1.2- 6.  CCM  Computation 


With  this  done,  a  normalized  crosscountry  mobility  factor 
Is  determined. 

•  Depending  on  the  computed  value,  the  500  meter  square  is  rated 
go,  inhibited,  slow,  very  slow,  stop. 

•  This  process  shall  be  repeated  by  the  computer  for  the  total 
area  selected,  stored  In  a  working  file  and  graphically  dis¬ 
played  when  desired.  On  a  19-Inch  diagonal  CRT,  at  a  scale 
of  1:50,000,  an  area  15  km  x  20  km  can  be  displayed  In 
1,200  blocks  500  meters  square. 

Lines  of  Communication  (LOC)  Overlay 

The  LOCs  shall  be  provided  as  source  data  in  vector  and  A/N  form 
(See  paragraph  3. 1.1.1)  and  shall  be  categorized  according  to  class  at 
this  stage.  Like  the  subfactor  overlays  and  the  CCM  itself,  the  LOCs 
are  echelon  independent.  Echelon  Is  accounted  for  during  the  corridor 
build  process  and  route  timing.  The  method  of  classifying  the  various 
LOC  categories  has  been  discussed.  In  detail,  in  Section  5  of  the  IPB/ 
TIAX  Phase  A  Final  Report. 

Figure  3. 1.2-7  shows  that,  to  the  analyst,  the  CCM  and  LOC  select 
processes  are  very  similar.  He  validates  weather  effects,  selects  the 
area  for  display  and  can  modify  the  source  data.  This  ability  to 
modify  LOC  source  data.  In  a  military  environment,  is  of  paramount 
Importance  to  the  analyst  because  of  the  vulnerability  of  roads, 
bridges,  tunnels,  etc.,  to  attack.  The  destruction  or  impairment  of 
any  of  these  Items  Is  Information  critical  to  the  analyst's  determin¬ 
ation  of  mobility  corridors. 


z. 
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An  additional  feature  shall  also  be  provided  for  the  LOC  function, 
viz..  Map  Reference  data.  This  can  be  any  A/N  data  containing  impor¬ 
tant  technical  characteristics  relative  to  the  LOC.  Although  the  item 
shall  be  Identified  by  graphic  cursor  Input,  the  data  shall  be  displayed 
on  the  A/N  display  so  as  to  keep  the  graphic  display  uncluttered. 

Combined  Obstacles  Matrix  (COM)  Build  Process 

Figure  3. 1.2-7  shows  the  COM  build  process.  In  the  figure,  two 
paths  shall  be  available  to  the  analyst  once  the  area  of  interest  has 
been  decided  upon.  The  one  path,  with  arrows  out  of  the  left  side  of 
the  functional  boxes  Is  highly  automatic.  Here,  the  analyst  simply 
calls  up  and  graphically  merges  the  COI  and  LOC  overlays  of  the  area 
through  the  graphic  terminal  (keyboard,  cursor  and  display). 

The  analyst  shall  also  be  able  to  call  up  as  separate  items  the 
soils,  vegetation,  slope,  LOCs,  or  CCM  overlays. 

The  second  path  In  the  figure,  with  arrows  from  the  center  of  the 
function  boxes.  Is  highly  Interactive.  It  assumes  that  the  analyst 
must  initialize  the  system  for  weather,  modify  certain  of  the  terrain 
subfactor  overlays  due  to  new  information,  build  a  new  CCM,  examine  and 
modify  the  LOCs  for  the  area  (e.g.,  blown  bridges)  and  finally  create 
the  COM  through  the  merge  process. 

The  main  purpose  of  the  COM  shall  be  to  aid  the  IPB  analyst  to 
Identify  and  build  potentially  favorable  corridors  of  movement  of  enemy 
forces  as  described  In  the  following  section. 


3-57 


3. 1.2. 2. 2  Mobility  Corridors 


Figure  3. 1.2-5  in  the  previous  section  is  a  color  photograph  of 
the  combined  obstacles  matrix  (COM).  This  portrays  the  net  effect  of 
all  terrain  influences  on  mobility  onto  one  display.  With  this  total 
mobility  picture,  plus  knowledge  of  the  enemy's  present  location  and 
an  assumption  about  his  probable  objectives,  the  analyst  can  identify 
potentially  favorable  corridors  of  movement  for  enemy  forces. 

The  mobility  corridor  overlay  shall  be  built  from  the  data  contained 
on  the  COM.  The  mobility  corridor  overlay  highlights  the  best  routes  for 
enemy  movement  across  the  terrain  in  question.  Mobility  corridors  are 
established  for  a  particular  force  echelon. 

The  corridor  build  and  rate  process  shall  be  both  iterative  and 
interactive  and  requires  analyst  awareness  of  the  tactical  environment. 
The  process  consists,  in  summary,  of  the  following  basic  steps: 

•  Build  a  crosscountry  corridor  on  the  CCM 

•  Determine  the  effect  of  river  and  stream  crossings  on  the 
crosscountry  corridor 

•  Build  road  corridors 

•  Cause  the  system  to  rate  the  overall  corridor  using  a  single 
color  corresponding  to  the  lowest  rated  (choke  point)  segment 
contained  in  the  corridor. 

The  analyst  shall  not  be  constrained  to  performing  the  above  four 
steps  In  specific  sequence.  He  may,  at  any  time,  intermix  the  building 
of  road  or  crosscountry  corridors,  or  look  for  alternate  paths  around 
the  observed  choke  point(s)  to  make  the  corridor  more  acceptable. 
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Implicit  to  this  process  is  the  ability  of  the  analyst  to  subdivide 
a  force  into  lower  echelons  (e.g.,  army  into  division,  divisions  into 
regiments,  etc.)*  This  provides  the  capability  of  using  multiple  smaller 
corridors  to  comprise  enough  throughput  for  higher  echelons  to  attain 
their  military  objectives. 

The  mobility  corridors  shall  also  be  modifiable  at  any  time  to 
reflect  implementation  of  friendly  obstacle  plans.  These  include 
preplanned  minefields,  obstacles,  blocking  positions,  etc.,  that  can 
change  the  mobility  corridor  picture.  This  modified  mobility  corridor 
normally  reflects  a  reduction  in  the  number  of  corridors  available  or 
the  mobility  rating  within  a  corridor. 

Figure  3. 1.2-8  is  a  description  of  process  flow  for  building  a 
mobility  corridor.  The  following  paragraphs  elaborate  on  each  element 
of  the  process.  Additional  details  on  corridor  rating  are  also  included 
in  Appendix  D. 

Initialization 


The  IPB  system  shall  be  initialized  through  the  graphics  function 
keyboard  by  selecting  the  echelon  expected  to  traverse  the  corridor  and 
the  COM  of  interest.  Map  scale  shall  be  included,  automatically,  as 
header  Information  and  weather  effects  through  the  previously  discussed 
weather  menu  Input  COM  build  process. 

Crosscountry  Corridor 

1.  The  analyst  through  the  graphics  function  keyboard  selects 
the  crosscountry  corridor  build  function.  Using  the  graphics 
cursor  he  draws  a  line  on  the  CRT  tracing  the  desired  course 
on  the  COM. 
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Figure  3. 1.2-8.  Mobility  Corridor  Process  Flow 


(Sheet  1  of  2) 


2.  When  the  desired  course  has  been  completed  by  the  analyst,  a 
polygon  is  created  whose  sides  are  parallel  to  the  vector 
trace  and  ends  are  normal  to  the  vector  trace  (see  Figure 

3. 1.2-9).  The  width  of  the  polygon  is  a  function  of  echelon; 
the  length  is  (approximately)  equal  to  the  vector  trace. 

This  polygon  is  used  for  computational  purposes  (Appendix  D) 
along  with  a  sliding  window. 

3.  A  sliding  window  constructed  and  controlled  by  the  system 
shall  then  be  used  to  build  the  corridor  (Appendix  D).  The 
length  of  the  window  shall  be  equal  to  the  width  of  the 
corridor  and  its  orientation  shall  be  normal  to  the  vector 
drawn  by  the  analyst  (Figure  3. 1.2-9). 

The  window  width  shall  be  equal  to  the  500  meter  COM  blocks. 

This  dimension  shall  be  changeable  through  the  graphic  function 
keyboard.  The  numbers  of  COM  blocks  falling  inside  the  sliding 
window  and  their  mobility  values  shall  be  determined  and  com¬ 
puted  in  terms  of  a  given  echelon  according  to  the  algorithm 
in  Appendix  D.  When  the  window  has  traversed  the  length  of 
the  vector  trace,  a  polychrome  corridor  shall  be  displayed 
to  the  analyst  on  the  graphics  screen  (Figure  3.1.2-10).  The 
color  of  the  segments  of  the  corridor  corresponds  to  the 
IPB(A)  five-part  mobility  rating:  green  =  go,  cyan  =  inhibited, 
yellow  =  slow,  magenta  =  very  slow,  red  *  no  go.  An  outline 
of  the  outside  edge  of  the  corridor  (polygon)  shall  also 
appear  along  with  the  corridor. 

The  pattern  of  the  corridor  (vertical,  diagonal,  horizontal, 
etc.,  cross-hatching)  designates  the  echelon  for  which  the 
evaluation  was  done.  In  the  case  of  Figure  3.1.2-10,  the 
pattern  is  for  a  regiment. 
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Figure  3. 1.2-9.  Crosscountry  Corridor  Polygon 


Figure  3.1.2-10  Polychrome  Crosscountry  Corridor  on  COM 


For  additional  details  on  the  specific  values  and  algorithms 
to  be  used  in  computing  the  windows  within  a  corridor,  refer 
to  Appendix  D. 

4.  If,  upon  examining  the  polychrome  corridor,  the  analyst  finds 
unacceptable  choke  points,  the  corridor  may  be  upgraded  by 
finding  an  alternate  path(s).  To  do  this,  the  analyst  shall 
utilize  a  modify  corridor  function,  which  permits  him  to 
delete  the  unacceptable  segment(s)  of  corridor,  trace  new 
paths  around  the  choke  point  and  have  the  new  segments  auto¬ 
matically  rated.  When  the  analyst  is  satisfied  he  merges 
the  modified  corridor  with  the  originally  defined  corridor. 

River  and  Stream  Crossing 

The  analyst  selects  the  River  Crossing  function  and  using  the  width 
of  the  previously  determined  crosscountry  corridor  to  determine  the  width 
of  the  river  crossing  to  be  considered  as  well  as  the  location  of  the 
crossing.  The  rivers  and  streams  shall  be  available  in  the  data  base 
coded  as  to  their  effect  on  mobility  (either  blue,  cyan  or  magenta  as 
defined  in  IPB/TIAX  Phase  A  Final  Report).  The  analyst,  using  the  graphic 
cursor,  draws  a  line  on  or  nearly  on  that  portion  of  the  river  to  be  crossed. 
A  program  search  is  done  to  locate  the  river/stream,  measure  the  width 
of  the  crossing  and  determine  the  stored  mobility  classification.  The 
computer  then  calculates  the  mobility  rating  for  that  segment  of  corri¬ 
dor,  compares  this  value  with  the  determined  values  of  the  corridor  for 
that  terrain  segment  and  stores  the  lower  of  the  two  mobility  ratings. 

That  segment  of  corridor  is  then  color  coded  according  to  this  stored 
mobility  rating. 
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Road  Corridor  Build 


The  analyst,  using  the  graphic  function  keys,  selects  the  LOC 
Corridor  Build  function  and  draws  a  line  on  or  near  the  road  to  be 
used.  The  search  algorithm  locates  the  road  segment  and  identifies 
its  stored  mobility  classification.  Then,  through  the  use  of  the 
algorithm  discussed  In  the  following  section,  the  road  corridor  rating 
shall  be  automatically  determined  and  graDhically  displayed  for  the 
selected  road  segment  and  echelon.  Figure  3.1.2-11  shows  an  example 
of  the  result  of  such  an  analysis  merged  with  the  previously  determined 
crosscountry  corridor.  Again,  the  color  of  the  corridor  represents  the 
IPB(A)  five-part  mobility  scale  and  the  pattern  represents  the  echelon. 

Computation  of  Road  Corridor 

The  Road  Corridors  shall  be  rated  according  to  the  following  set 
of  rules.  First,  the  rate  of  delivering  a  force  as  a  function  of  echelon 
in  equivalent  battalions  per  hour  is  defined  as  follows: 


bn 

hr 


(1) 


where , 

A^  «  battalions  per  hour  for  echelon  of  type  "E" 

Vj  *  normalized  speed  for  a  given  road  rating  (see 
table  "a"  of  Figure  3.1.2-12) 

*  doctrinal  speed  (see  table  a.  Figure  3.1.2-12)  for 
product  VjSD) 
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Figure  3. 1.2-1 1  Polychrome  Crosscountry  and  Road  Corridor  on  COM 


SPEED  (VT  x  Sq) 

NORMALIZED  SPEED  (VT) 

White 

25  km/hr 

1.0 

Green 

25  km/hr 

1.0 

Cyan 

12  km/hr 

0.5 

Yellow 

6  km/hr 

0.25 

Magenta 

2  km/hr 

0.0825 

(a)  Road  Speed 


ECHELON 

TYPE 

DOCTRINAL  ROAD  LENGTH  (LQE) 

EQUIVALENT  NUMBER 

OF  BATTALIONS  (E£) 

SINGLE  COLUMN 

PARALLEL  COLUMN 

Battal  Ion 

5  km 

N.A. 

1  Bn/Bn 

Regiment 

25  km 

N.A. 

5.5  Bn/Reg 

Division 

145  km 

80  km 

22  Bn/DIv 

(b)  Echelon  Parameter 


ROAD  CORRIDOR  RATING 

ROAD  CORRIDOR  CATEGORY  BOUNDARIES 

GO  (Green) 

INHIBITED  (Cyan) 

SLOW  (Yellow) 

VERY  SLOW  (Magenta ) 

STOP  (Red) 

Ae  *  4.2 

22.1  A£  <  4.2 

20.9  A£  <  2.1 

20.25  A£  <  0.9 

Ae  <  0.25 

(c)  Road  Corridor  Category  Boundaries 


Figure  3.1.2-12.  Doctrinal  Data  for  Roads 
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i 


*  equivalent  number  of  battalions  for  echelon  type 
"E"  (battalions/echelon  type)  (see  Figure  3.1.2-12, 
table  b  for  values  of  E^) 

Lqe  =  doctrinal  road  length  of  echelon  type  E  (kilometer/ 
echelon  type)  (see  Figure  3.1.2-12,  table  b  for  value 
of  Lde) 

Using  the  doctrinal  data  contained  in  tables  "a"  and  "b"  of 
Figure  3.1.2-12  and  the  corridor  boundaries  listed  in  table  "c"  of 
the  same  figure,  the  table  contained  In  Figure  3.1.2-13  is  generated. 
The  table  converts  the  computed  value  of  into  road  corridor  rating. 
This  table  shall  be  changeable  offline  to  reflect  doctrinal  differences 
associated  with  the  rates  of  movement  and  equipment  capabilities  and 
the  organization  of  specific  enemy  forces. 

Corridor  Rating 

Upon  satisfactory  completion  of  the  corridor  build  process  using 
roads,  crosscountry  and  -iver  and  stream  effects,  the  analyst,  through 
graphic  cursor  and  function  key  input  shall  paint  the  total  corridor 
the  color  of  the  lowest  rated  segment  (choke  point)  within  the  corridor 
(see  Figure  3.1.2-14).  The  analyst  shall  be  able  to  delete  the  CCM 
portion  of  the  COM  and  keep  the  corridor(s)  and  roads  merged  as  shown 
in  Figure  3.1.2-15. 


3. 1.2. 2. 3  Intervisibility  Corridors 

The  IPB(A)  approach  to  Intervislbllity  Is  explained  in  the  TIAX 
Phase  II  Interim  Report  published  17  August  1979.  The  approach  Is 
similar  to  the  way  mobility  corridors  are  constructed  In  that  It  uses 
a  base  Intervislbllity  overlay  on  which  a  vector  is  traced  along  a 


Figure  3.1.2-13.  Road  Corridor  Rating  Data 
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Figure  3.1.2-14  Rated  Regimental  Corridor  on  COM 
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Figure  3.1.2-15  Rated  Corridor  on  Map 


given  direction  from  a  selected  vantage  point  to  build  an  intervisi¬ 
bility  corridor.  The  flow  of  man/machine  functions  required  to  build 
intervisibility  overlays  and  corridors  is  illustrated  in  Figure  3.1.2-16. 
As  shown,  the  process  requires  that  an  intervisibility  overlay  first 
be  constructed  for  the  area  of  interest.  This  overlay  in  itself  is 
quite  useful  to  address  certain  intervisibility  considerations.  When 
a  particular  line-of-sight  (LOS)  is  defined  to  the  system  the  inter- 
visibility  corridor  build  process  is  involved. 

The  following  sections  will  describe  in  more  detail  the  inter¬ 
visibility  overlay  and  intervisibility  corridor  build  processes. 

Intervisibility  Overlay 

The  intervisibility  overlay  is  built  by  logically  combining  (see 
Figure  3.1.2-17)  classes  of  vegetation  with  surface  configuration  and 
built-up  areas.  The  same  terrain  source  data  is  used  to  build  the  inter¬ 
visibility  overlay  as  was  used  for  the  CCM  build  process.  At  the  top  of 
the  illustration  are  charts  that  cross-reference  the  terrain  data  types 
with  the  three  Intervisibility  codes.  Code  definitions  are  listed  at 
lower  left,  and  the  logic  used  to  form  the  overlay  is  indicated  in  the 
center.  Figure  3.1.2-18  is  a  photograph  of  a  CRT  version  of  an  inter¬ 
visibility  mosaic.  In  the  photo  the  most  dense  green  dot  pattern  por¬ 
trays  the  V5,  Cover  and  Concealment  category;  the  least  dense  green  dot 
pattern  portrays  the  V4,  Close  Combat  Engagement  category;  the  empty 
(black)  squares  portray  V3,  Direct  Fire  Weapons  category. 

The  steps  necessary  to  build  an  intervisibility  overlay  are  as 
follows: 


Figure  3.1.2-18  Example  —  Intervlalblllty  Overlay 


•  Input  weather/season  effects  as  discussed  in  Section  3. 1.2.1. 
(Note  that  it  is  not  necessary  to  perform  this  operation 
each  time  an  intervisibility  overlay  is  to  be  built.) 

•  The  analyst  through  the  graphic  terminal  shall  select  the 
area  of  interest  and  the  function  to  be  performed,  e.g., 
display  Intervisibility  overlay  for  selected  area. 

•  The  computer  shall  modify  the  stored  terrain  data  codes  into 
appropriate  IPB(A)  intervisibility  codes  using  the  weather 
factor  tables  as  defined  by  operator  inputs. 

•  The  computer  logically  combines  the  surface  configuration 
intervisibility  factor  with  the  vegetation  intervisibility 
factor  with  the  built-up  area  intervisibility  factor.  With 
this  done,  the  Intervisibility  factor  for  that  500  meter 
square  is  determined. 

•  Depending  on  the  value  determined,  the  500  meter  square  is 
rated  as  Cover  and  Concealment,  Close  Combat  or  Direct  Fire. 

•  This  process  shall  be  repeated  by  the  computer  for  the  total 
area  selected  by  the  analyst.  It  shall  be  stored  in  a  working 
file  and  graphically  displayed  when  desired.  On  a  19-inch 
diagonal  CRT,  at  a  scale  of  1:50,000,  an  area  of  15  km  x  20  km 
can  be  displayed  utilizing  1,200  Intervlsibllity  blocks. 

Intervisibil ity  Corridors 

The  construction  of  the  Intervlsibllity  corridors  shall  be  dependent 
on  both  the  military  situation  and  line-of-site  (LOS)  Interest.  Again, 
the  terrain  source  data  used  for  the  mobility  and  intervlsibllity  build 
processes  shall  be  used. 
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The  determination  of  Intervisibility  corridors  requires  the  inclu¬ 
sion  of  two  factors  (in  addition  to  others  previously  mentioned)  to  each 
500  meter  block  code:  average  tree  height  and  average  elevation. 

Average  tree  height  is  determined  from  vegetation  data  and  classified 
Into  four  categories:  25  meters,  12  meters,  3  meters  and  0  meter. 
Average  block  elevation  can  be  determined  from  the  topographic  map. 

The  process  to  be  followed  by  the  analyst  in  building  an  inter- 
visibility  corridor  is  flow  charted  in  Figure  3.1.2-16  and  includes 
the  following  steps: 

•  The  Initialization  step  took  care  of  selecting  appropriate 
terrain  data  as  affected  by  weather/seasonal  effects. 

Weather  data  Inputs  would  also  limit  LOS  as  a  function  of 
atmospheric  attenuation. 

•  The  analyst,  through  graphic  cursor  and  function  keys,  selects 
the  area  of  interest,  map,  intervisibility  overlay,  indicates 
the  desired  LOS  direction,  and  locates  the  vantage  point. 

•  The  system  automatically  computes  the  intervisibility 
corridors  and  presents  a  graohic  display  like  that  shown 
In  Figure  3.1.2-19.  In  the  figure,  the  very  dense  green 
dot  pattern  represents  the  areas  which  are  masked  from 
observation  from  the  selected  vantage  point  by  intervening 
terrain.  Those  unmasked  pattern  blocks,  then,  are  visible 
to  the  observer  and  constitute  the  Intervisibility  corridors. 

In  making  the  calculation,  the  observer's  field  of  view  Is  con¬ 
sidered  unlimited  unless/until  obstructed  due  to  intervening  terrain 
elevation.  The  observer  is  assumed  to  be  at  the  center  of  the  vantage 
point  block,  3  meters  above  the  average  terrain  elevation  of  the  block. 
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Figure  3.1.2-19  Example  —  Intelligibility  Overlay  and  Corridor 


When  an  area  is  blocked  due  to  elevation,  the  original  intervisibility 
overlay  pattern  is  replaced  by  the  most  dense  pattern.  If  no  elevation 
blockage  occurs,  the  original  intervisibility  overlay  pattern  remains. 

Figure  3.1.2-20  illustrates  the  elements  of  the  problem.  For 
positive  elevation  angles  to  the  observed  area,  an  intervening  block 
can  mask  the  observed  block  if  the  elevation  angle  to  the  intervening 
block  can  mask  the  observed  block  if:  (1)  the  elevation  angle  to  the 
Intervening  area  is  negative  In  value  and  has  a  smaller  absolute  value 
than  the  absolute  value  of  the  elevation  angle  to  the  observed  area,  or 
(2)  has  a  positive  elevation  angle.  The  convention  used  for  elevation 
angles  is:  positive  if  above  the  horizontal  and  negative  if  below  the 
horizontal.  The  angle  would  be  calculated  as  follows: 

elevation  angle  -  arc  tan  (^~ I— -) 


where,  A  *  average  tree  height  of  intervening  areas 

B  =  average  ground  elevation  of  intervening  or  observed  area 
C  *  average  ground  elevation  of  observer  area  plus  3  meters 
D  »  distance  from  center  point  to  center  point  of  the  two 
blocks  under  consideration 

Development  of  an  intervisibility  corridors  overlay  involves  the 
calculation  of  elevation  angles  between  the  observer  and  all  intervening 
blocks  In  the  defined  area  and  then  comparing  these  elevation  angles  to 
determine  where  masking  by  Intervening  blocks  takes  place. 
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Observed  Area 


Flqure  3.1.2-20.  Intervisibility  Corridor  Determination 


3. 1.2. 2. 4  Route  Timing  Calculation  and  Display 

To  perform  route  timing,  the  analyst  shall  Input  the  three  parame¬ 
ters  listed  below.  Map  scale  (1:50,000  or  1,250,000)  shall  be  Included 
as  part  of  the  map  record  and  shall  not  be  a  required  input.  Then, 
using  the  graphic  cursor  and  the  previously  defined  nobility  corridor, 
the  analyst  shall  trace  a  vector  across  the  corridor  to  be  traversed. 
Upon  completion  of  the  trace  the  computed  times  shall  automatically 
appear.  Figure  3.1.2-21  Is  a  photograph  of  a  graphic  display  showing 
the  calculated  Arrival  Times  for  two  routes  computed  by  two  different 
methods:  incremental  and  cumulative.  The  IPB  system  shall  also 
compute  cumulative  and  Incremental  Pass  Times.  The  following  are 
definitions  of  terms  pertinent  to  an  explanation  of  the  process: 

•  Arrival  Time  -  the  time  the  head  of  the  column  and  the 

unit  being  measured  reaches  a  designated 
point,  line  or  object 

•  Pass  Time  -  the  time  between  when  the  first  element  of 

the  unit  being  measured  passes  a  given  point 
and  when  the  last  element  passes  the  same 
point 

•  Column  roadway  (corridor)  occupied 

by  a  column  In  movement.  Including  the  gaps 
Inside  the  column  measured  from  the  front 
to  the  rear.  Inclusive. 

The  three  Input  parameters  of  category,  class  and  mode,  are  described 
In  the  following  subparagraphs: 
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Figure  3.1.2-21  Route  Timing 


1.  Category  -  The  analyst  shall  select  category  as  either  roads 
or  crosscountry.  The  doctrinal  speed  of  a  unit  on  a  road  is 
different  from  the  doctrinal  speed  for  crosscountry  movement. 
Category  is  determined  by  visual  inspection  of  the  corridor. 

2.  Class  -  The  mobility  category  (color)  of  the  element  being 
timed.  For  road  corridors  there  are  five  classes:  white, 
green,  cyan,  yellow,  magenta.  For  crosscountry  corridors 
there  are  four  classes:  green,  cyan,  yellow,  magenta. 

Class  is  also  determined  by  visual  inspection  of  the  corri¬ 
dor.  The  corridors  shall  be  monochrome,  coded  at  the  lowest 
rated  color  for  similar  categories. 

3.  Mode  -  One  of  four  time  modes  shall  be  selectable  by  the 
analyst: 

Mode  1  *  Incremental  Pass  Time 
Mode  2  =  Incremental  Arrival  Time 
Mode  3  =  Cumulative  Pass  Time 
Mode  4  =  Cumulative  Arrival  Time 

Pass  versus  Arrival  time  designates  the  method  of  calculation 
by  the  system. 

Pass  times  shall  be  calculated  as: 

(1) 
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Arrival  times  shall  be  calculated  as: 


(2) 


Where,  A  *  Length  of  road  seqment  to  be  traversed 
by  unit  (km) 

B  =  Doctrinal  column  length  of  unit  (km) 

C  =  Speed  of  travel  (km/hr) 

Incremental  versus  Cumulative  time  characterizes  the  data  to 
be  displayed. 

Incremental  Time  -  In  this  mode,  the  analyst  shall 
designate  time  point  positions  through  cursor  placement 
and  position  entry.  When  two  time  points  have  been 
entered,  the  time  to  move  between  the  two  points  shall 
be  calculated  and  displayed  midway  between  the  points. 


1  2  3 
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Cumulative  Time  -  For  this  mode,  the  course  shall  be 
traced  as  in  the  Incremental  time  mode. 


However,  upon  completion  of  the  course  trace,  the  input 
course  trace  positions  shall  be  deleted  from  the  display 
and  the  course  shall  be  divided  into  equal  time  incre¬ 
ments  and  the  time  shall  be  placed  in  close  proximity  to 
the  time  symbol . 


30  25  20  15  « 
0 0 0 0"  'u 


Default  values  for  the  time  increments,  as  a  function 
of  scale  shall  be  included.  However,  for  greater  flexi¬ 
bility,  the  operator  should  also  be  able  to  manually 
select  values,  e.q.,  5  min,  10  min,  15  min,  30  min. 

It  should  be  noted  that  Echelon  is  not  a  required  initialization 
parameter.  The  timing  computation  is  based  on  the  fact  that  for  cross¬ 
country  movement,  a  green  corridor  is  equivalent  to  12  km  per  hour, 
cyan  corridor  equivalent  to  6  km  per  hour,  yellow  is  3  km  per  hour, 
magenta  is  1  km  per  hour  and  red  is  zero.  Further,  the  color  of  the 
corridor  is  based  on  the  echelon  travesing  the  corridor.  Since,  a 
green  corridor  for  battalion  may  be  a  different  rate  for  a  different 
echelon,  and  since  the  analyst  Input  the  corridor  color,  timing 
implicitly  accounts  for  echelon. 
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3. 1.2. 3  IPB  Template  Products 

There  are  10  IPB  templates  or  matrixes  which  are  to  be  created 
using  basic  Input  data  and  the  IPB  system  capabilities.  They  are: 

•  Planned  Routes 

•  Snapshot  lines 

•  Snapshots 

•  Situation  templates 

•  Event  matrixes 

•  Event  templates 

•  Target  analysis  matrixes 

•  Target  templates 

•  Decision  alternative  templates 

•  Decision  support  templates 

The  following  subsections  describe  which  software  functional 
capabilities  are  required,  how  these  capabilities  are  used  by  the 
IPB  analyst  and  contain  an  example  of  that  IPB  product. 

3. 1.2. 3.1  Planned  Routes 

Figure  3.1.2-22  shows  the  software  support  required  to  build  planned 
routes.  The  basic  inputs  to  this  function  are  the  current  situation 
display  and  the  doctrinal  template(s)  for  enemy  option(s).  Using  these 
items  with  maps  and  terrain  data  the  IPB  analyst  determines  the  most 
logical  routes  (of  advance)  the  eneiqy  would  use  to  reach  his  objectives. 
He  does  this  by  reviewing  on  the  graphics  CRT  a  merged  set  of  overlays: 
a  map  with  the  current  situation  and  one  of  the  enenjy  option  doctrinal 
templates.  The  purpose  of  this  review  is  to  determine  the  graphic  area 
wherein  the  enemy  operation  will  likely  occur  by  identifying  potential 
routes . 
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Figure  3.1.2-22.  Function:  Planned  Routes  (Sheet  2  of  4) 


The  next  subfunction  begins  with  the  IPB  analyst  calling  up  an 
A/N  menu  of  formats  and  selecting  from  It  the  format  for  applying 
weather  conditions  to  mobility.  Figure  3.1.2-23  Is  an  example  of  the 
first  menu  and  Figure  3.1.2-24  Is  an  example  of  a  weather  Input  format. 
The  purpose  of  this  subfunction  Is  to  ensure  the  appropriate  weather 
conditions  are  used  In  mobility  analysis.  The  IPB  analyst  interactively 
chooses  mobility  and  Intervisibility  conditions  wlhtln  the  areas  encom¬ 
passing  the  potential  routes  using  menus,  light  pen  and/or  keyboard  and 
latest  weather  forecasts  (see  Section  3. 1.2.1  for  details).  Once  the 
appropriate  conditions  have  been  specified,  the  CCM  computation  algorithm 
prepares  the  CCM,  LOC  and  COM.  The  intervisibility  overlay  can  also  be 
prepared  at  this  time.  These  can  be  viewed  on  the  graphic  CRT  and  are 
stored  for  later  use. 

Next  the  corridor  painting  and  rating  process  Is  used  to  determine 
the  best  road  and  crosscountry  corridors  for  that  enemy  option.  Then 
the  system  graphic  function  software  for  shading  polygons  Is  employed 
to  color  code  the  corridors  superimposed  upon  the  map  of  the  area.  The 
resultant  product— Planned  Routes—can  be  viewed  and  stored  on  a  work 
file  for  later  use.  Figure  3.1.2-25  Is  an  example  of  a  completed  Planned 
Routes  scene.  It  Is  overlayed  on  a  1:250,000  scale  map  and  depicts  the 
optimum  routes  for  advance  of  two  enemy  second  echelon  divisions  to 
execute  a  double  envelopment  option. 

3. 1.2. 3. 2  Snapshot  Lines 

The  snapshot  lines  build  function  Is  depicted  In  Figure  3.1.2-26. 

Its  purpose  Is  to  determine  those  key  points  In  each  option  where 
snapshots  will  be  developed.  It  results  from  merging  the  situation 
with  doctrine  and  terrain  In  the  area  of  Interest. 
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Figure  3.1.2-23.  Weather  Update  Menu 


Figure  3 .7.2-24.  CCM  Overlay  Initialization  Menu 


Figure  3.1.2-25  Planned  Routes  Example 
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Figure  3.1.2-26.  Function:  Snapshot  Lines  (Sheet  1  of  2) 
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The  IFB  analyst  selects  the  enen\y  option  for  which  he  wants  to 
develop  snapshots.  Through  the  function  keyboard  he  selects  the 
planned  routes  overlay  for  that  ootlon  and  an  appropriate  map  back¬ 
ground.  With  this  composite  display  on  the  graphic  CRT  he  also  merges 
the  planned  routes  overlay  for  other  enemy  options  (in  a  different 
color)  one  at  a  time.  The  two-color  display  permits  the  analyst  to 
determine  visually  which  portions  of  the  selected  option  are  unique 
to  it.  At  the  same  time  he  can  identify  visually  any  key  direction 
indicators  (turns)  on  that  unique  route  which  would  aid  in  determining 
if  the  enemy  were  executing  that  option.  These  indicators  are  marked 
on  the  display  by  drawing  circles  at  those  geographic  locations.  The 
analyst  next  calls  the  doctrinal  option  template  for  the  selected  option 
from  the  doctrinal  template  file  and  merges  this  template  on  the  graphic 
CRT.  (The  analyst  may  use  system  graphic  functional  capabilities  to 
suppress  certain  portions  of  the  display  to  reduce  clutter,  if  necessary.) 
The  doctrinal  template  is  positioned  by  superimposing  its  focal  point 
with  the  corresponding  point  on  the  display  and  setting  its  direction 
to  fit  the  display. 

Since  uniqueness  Is  a  key  criterion  for  snapshots,  the  unique 
route(s)  for  the  selected  option  are  the  basis  for  the  next  step.  The 
analyst  uses  the  Annotate  functional  capability  to  mark  positions  on 
the  unique  route (s)  where  snapshots  are  desired.  This  process  is  done 
by  visually  adjusting  the  doctrinal  lines  to  the  terrain  and  the  key 
elements  of  the  current  enemy  situation.  The  geographic  locations 
along  the  key  route  in  that  option  at  which  snapshots  should  be  plotted 
have  now  been  determined. 

Next  the  analyst  must  work  out  where  other  enemy  force  elements 
within  that  option  should  be  plotted  on  each  snapshot.  To  do  this  the 
analyst  employs  the  functional  capability  to  do  Route  Timing  (see 
Section  3. 1.2. 2. 4).  He  will  normally  accomplish  route  timing  beginning 


# 
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at  the  line  of  contact  and  working  rearward  toward  the  assembly  areas, 
or  known  enemy  unit  locations.  This  procedure  Is  based  on  enemy  doc¬ 
trine  that  attacking  forces  will  attempt  to  reach  line  of  contact 
simultaneously.  On  the  unique  route  the  analyst  utilizes  the  cumulative 
capability  of  the  Route  Timing  algorithm.  Then  he  applies  the  same 
capability  to  the  other  route(s)  in  that  option.  The  display  which 
contains  the  results  of  the  route  timing  algorithms  is  stored  on  the 
working  file. 

The  IPB  analyst  next  assembles  a  display  on  the  graphic  CRT  which 
consists  of  a  map  background,  the  planned  routes  for  the  option  being 
considered,  the  snapshot  line  annotations  and  the  cumulative  route 
timing  results.  He  uses  the  system  graphic  function  draw  dashed  lines 
and  connects  the  time  associated  with  the  snapshot  line  annotations  on 
the  unique  route  with  the  same  times  on  the  other  route(s)  in  that 
option.  Once  all  snapshot  lines  have  been  drawn  the  display  may  be 
de-cluttered  by  suppression/deletion  of  the  time  results  and  the 
planned  routes. 

The  last  step  is  to  again  use  the  route  timing  algorithm  to 
develop  the  elaosed  time  between  snapshots.  The  analyst  utilizes  the 
incremental  capability  of  the  route  timing  algorithm,  marking  the 
snapshot  lines  as  the  points  for  timing  computation.  The  resulting 
display  is  indexed  and  stored  on  the  working  file. 

Figure  3.1.2-27  is  an  example  of  the  completed  snapshot  lines 
overlay  as  stored  in  the  IPB  analyst's  file.  The  process  is  repeated 
for  each  enemy  option. 
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Figure  3.1.2-27  Snapshot  Lines  Example 


3. 1.2. 3. 3  Snapshots 


Figure  3.1.2-28  Is  a  representative  snapshot  at  1:250,000  scale. 
Each  situation  snapshot  is  a  graphic  of  postulated  overall  enemy  unit 
locations  at  an  Instant  in  time  in  a  single  option  on  analyzed  terrain. 
Some  5  to  8  snapshots  along  mobility  corridors  are  prepared  to  represent 
the  execution  of  one  option  from  Inception  to  objective. 

Figure  3.1.2-29  diagrams  the  building  of  one  snapshot,  snapshot 
A2.  Working  from  his  knowledge  of  enemy  options  and  from  examination 
of  the  Option  A  Planned  Routes  and  Snapshot  Lines  templates,  the  analyst 
identifies  the  next  snapshot  he  will  build.  For  Snapshot  A2,  he  selects 
the  appropriate  1:250,000  scale  L0C  map;  he  selects  the  Option  A  Snap¬ 
shot  Lines  template.  On  input  key  command,  the  system  automatically 
merges  these  overlays  at  a  selected  scale.  He  may  also  merge  the 
mobility  corridors  overlay  associated  with  the  planned  routes  on  the 
screen  as  a  third  overlay. 

The  analyst  begins  building  snapshot  symbols.  He  overlays  on  the 
working  display  a  doctrinal  template  of  a  regiment  in  road  column 
formation.  He  aligns  the  main  body  lead  symbol  of  the  doctrinal  tem¬ 
plate  with  the  intersection  of  the  A2  snapshot  line  and  the  mobility 
corridor.  He  reorients  the  doctrinal  template  to  the  direction  of 
overall  movement.  Then  he  builds  the  unit  symbols  which  are  to  be 
a  part  of  the  overall  template.  He  repeats  this  process  on  each 
corridor.  To  place  additional  units  which  are  attached  from  higher 
echelons,  he  overlays  division  slice  doctrinal  templates.  He  proceeds 
in  this  manner  to  build,  symbol  by  symbol,  a  representation  of  the 
entire  force  defined  in  this  option  and  course  of  action. 
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Figure  3.1.2-28  Snapshot  Example 


Figure  3.1.2-29.  Snapshot  Build  Process  (Sheet  1  of  2) 
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He  can  next  call  on  the  tabular  screen  sets  of  EOB  data  to  assist 
In  verifying  that  he  has  accounted  for  all  units.  If  EOB  units  are 
missing  from  the  working  display,  he  adds  them  to  the  template  picture, 
deriving  their  positions  from  division  and  regimental  slice  templates 
and/or  from  his  knowledge  of  enemy  fighting  doctrine  which  may  be 
supplemented  by  non-automated  support  files. 

At  the  point  when  all  snapshots  are  built  for  all  options,  the 
analyst  next  wants  to  Identify  units  that  are  unique  to  this  option 
and  which  therefore  can  be  used  as  discriminators  In  separating  options. 
Via  Input  key  control,  he  calls  and  merges,  one  at  a  time,  every  other 
snapshot,  not  of  the  same  option,  that  has  been  built  to  deal  with  this 
enemy  force  as  it  attempts  to  achieve  Its  major  objective.  As  each 
comparison  snapshot  Is  merged  the  analyst  uses  the  special  function. 
Symbol  Matching,  which  automatically  finds  common  units  (any  unit  on 
the  Snapshot  A2  template  which  is  within  5  kilometers*  of  a  unit  of 
matching  type  and  echelon  on  a  different  template).  In  this  application 
the  primary  symbol (s)  are  those  of  Snapshot  A2.  The  result  is  that 
"Bitched  A2  (primary)  symbols  will  be  re-coded  (color  coded)  as  common. 
When  this  step  of  the  process  is  complete,  the  Snapshot  A2  template 
shows  a  set  of  unique  units  In  one  color  and  a  set  of  common  units  in 
a  different  color. 

The  analyst  next  wants  to  add  to  this  template  all  current 
situation  units  reported  to  be  In  the  same  area.  If  what  he  has  been 
templatlng  Is  a  new  area  of  operations  not  previously  under  assault, 
there  would  be  no  existing  units  to  be  added.  If  he  Is  templatlng  a 
force  such  as  a  large  reserve  force  which  is  moving  into  a  previously 


*A  variable  distance  which  can  be  reset  by  the  operator. 
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contested  area  of  operations,  there  would  be  existing  units  to  be 
added.  In  the  latter  case,  the  analyst  accesses  the  enemy  portion  of 
the  current  situation  and  merges  It  onto  his  IPB  graphic  screen  to 
complete  the  snapshot.  The  analyst  may  now  adjust  individual  symbols 
positions  (but  not  origins)  to  declutter  the  screen. 

When  satisfied  with  the  template  picture,  he  will  add  pertinent 
military  data  Including  the  line  of  contact,  phase  lines  and  military 
boundaries.  He  adds  an  Identifying  number  and  time  stamp  and  stores 
the  product  In  the  system  permanent  file.  The  system  automatically 
updates  its  Indexes  to  reflect  this  item. 

3. 1.2. 3. 4  Situation  Templates 

Figures  3.1.2-30  and  3.1.2-31  are  examples  of  situation  templates 
at  a  1:50,000  scale.  Each  situation  template  is  a  portion  of  a  situation 
snapshot  graphic  highlighting  those  unit  configurations  unique  to  this 
option  which  enable  the  analyst  to  distinguish  between  this  and  other 
options.  Several  situation  templates  may  be  associated  with  one 
situation  snapshot. 

Figure  3.1.2-32  diagrams  the  steps  in  building  a  situation 
template.  The  analyst  starts  by  displaying  one  snapshot  (Snapshot  A2 
in  this  example)  and  determines  which  of  the  unique  elements  shown 
should  be  highlighted  by  a  situation  template.  In  response  to  an 
analyst  input,  the  system  automatically  offsets  and  expands  the 
selected  field  of  view  from  the  snapshot  scale  of  1:250,000  up  to  the 
1:50,000  scale  of  the  situation  template.  The  system  automatically 
transfers  to  the  enlarged  scale  all  L0C  map  details  and  unit  symbols 
within  that  field  of  view. 


!-.W  Situation  Template  Kxample  Road  Mart'll 
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Figure  3.1.2-31  Situation  Template  Example  —  Attack  Formation 


njnCTIfW 


aumir 


B3ggD  OtagTIg  WTO: 


1.  «m*Mc  FmcMm  (Sw  Mctta*  1.2.3) 
L  iNctel  Newt  Bg  liwrtlii  tl) 


i 


i 


VtV;! 


Situation  Template  Build  Process  (Sheet  2  of  2) 
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The  analyst  next  will  modify  each  symbol  as  required  making  it  the 
desired  unit  and  echelon  representation  for  situation  template  use.  He 
will  call  an  appropriate  doctrinal  template  at  the  1:50,000  scale,  align 

it  with  a  transferred  symbol  and  then  build  a  new  symbol  to  replace  the 
regiment  or  battalion  symbol  transferred  from  the  snapshot.  In  areas 
forward  of  the  deployment  line,  he  will  utilize  doctrinal  templates 
depicting  battalions  in  a  regimental  combat  formation.  On  weather 
modified  terrain,  he  will  position  battalion  symbols  to  replace  regi¬ 
ment  symbols  transferred  from  the  snapshot.  He  will  continue  building 
symbol  by  symbol  in  this  manner  until  he  has  an  adequately  detailed 
situation  template. 

He  may  further  refine  the  unit  positions  by  utilizing  the  ground 
Intervisibility  rating  process.  For  any  units  in  question,  he  calls 
and  the  system  merges  the  Intervisibility  overlay  for  the  area.  He 
inputs  an  intervisibility  rating  request,  indicating  the  desired  vantage 
point  and  llne-of-sight  vector,  and  the  system  automatically  computes 
and  displays  (in  the  form  of  color  coded  mosaic  squares)  what  areas  are 
visible  from  the  selected  vantage  point.  Depending  upon  the  rating  of 
the  selected  unit  position,  he  may  move  the  unit  symbol  to  a  better 
position.  Upon  completion  of  the  intervisibility  analysis  the  analyst 
will  delete  the  last  Intervisibility  corridor.  The  graphic  CRT  will 
now  contain  the  fully  adjusted  situation  template  which  consists  of 
symbols  which  are  scaled  representations  of  maneuver  forces  in  march 
route  formation  or  deployed  for  combat.  Unique  units  will  be  colored 
magenta;  units  which  are  common  to  more  than  this  option  will  be  colored 
red. 
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When  satisfied  with  the  template,  he  will  add  pertinent  military 
data  including  the  line  of  contact,  phase  lines  and  military  boundaries. 
He  adds  an  Identifying  number  and  time  stamp  and  stores  the  product  in 
the  system  permanent  file.  The  system  automatically  updates  its  indexes 
to  reflect  this  Item. 

3. 1.2. 3. 5  Event  Matrixes/ Event  Templates 

An  Event  Matrix  is  a  tabular  list  of  events  that  immediately 
follow  the  time  period  represented  by  a  Snapshot  Template.  It  focuses 
on  recognizable,  near  term  activitfes  in  a  time  sequence.  It  relates 
each  event  to  a  geographic  location  by  NAI  (named  area  of  interest). 

An  Event  Template  graphic  accompanies  each  Event  Matrix.  The  graphic 
is  a  layout  of  event  symbols  on  a  scaled,  gridded  background  map.  Each 
event  symbol  Is  Included  within  a  numbered  NAI  circle  or  ploygon.  The 
NAI  number  on  the  graphic  also  appears  as  n  entry  on  the  Event  Matrix. 
An  Index  Is  provided  to  cross-reference  individual  events,  NAIs,  event 
templates  and  snapshot* templates. 

Figures  3.1.2-33  and  3.1.2-34  are  examples  of  an  Event  Matrix  and 
an  Event  Template  respectively. 

Figure  3.1.2-35  diagrams  the  build  process  for  constructing  an 
Event  Matrix  and  Event  Template.  Starting  at  the  top  of  the  diagram 
the  analyst  from  knowledge  of  the  option  and  working  from  the  Snapshot 
Lines  Template  for  that  option,  identifies  the  next  Event  Matrix/Event 
Template  pair  he  will  build.  He  selects  overlays  to  be  merged  on  the 
graphic  screen.  These  will  Include  background  maps  with  lines  of 
communication;  snapshot  templates  whhich  precede  and  follow  in  time 
sequence  the  Event  Matrix  time  period;  and  corridor  graphic  overlays. 
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EVENT  MATRIX  A2 
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Figure  3.1.2-33.  Event  Matrix  Example 
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Figure  3.1.2-35. 


Function:  Event  Matrix/Event  Template  (Sheet  1  of  2) 
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He  next  selects  from  a  tabular  menu,  a  Doctrinal  Event  Menu.  This 
is  a  prestored  menu  of  events  which  are  doctrinal ly  associated  with 
this  option  type/course  of  action.  Having  selected  from  this  list  a 
key  event  for  Inclusion  in  the  Event  Matrix,  he  calls  to  the  tabular 
screen  the  preformatted  Event  Matrix  List.  He  enters  the  description 
of  the  key  event.  If  the  description  contained  In  the  doctrinal  menu 
is  sufficient,  he  can  transfer  It  by  means  of  light  pen  or  similar 
control  device  to  save  typing.  He  will  complete  the  brief  text 
description  and  time  sequence  but  not  the  location  coordinates  and 
not  the  reference  to  the  NAI  number. 

The  analyst  shifts  his  attention  to  the  graphic  screen.  Examining 
the  event  description  and  time  just  entered  on  the  tabular  screen,  and 
examining  the  composite  overlay  set  on  the  graphic  screen,  he  locates 
the  symbol (s)  for  the  new  event.  He  queries  the  system  for  the  symbol 
coordinates  and  then,  returning  to  the  tabular  screen,  he  enters  the 
coordinates  for  this  event. 

He  continues  this  process  until  he  has  completed  all  desired 
entries  on  the  Event  Matrix  and  built  the  corresponding  symbols  on 
the  Event  Template.  Inspecting  the  Event  Template,  he  then  groups 
event  symbols  into  clusters  constructs  a  circle  on  polygon  around 
each  cluster  and  assigns  NAI  numbers. 

He  next  enters  the  NAI  numbers  opposite  the  appropriate  event 
descriptions  on  the  Event  Matrix. 

Vihen  satisfied  with  the  matrix  and  template,  he  adds  Identifying 
numbers  and  time  stamps  and  stores  the  products  In  the  system  permanent 
files.  The  system  automatically  updates  its  Indexes  to  reflect  these 
products.  The  system  automatically  updates  a  Cross  Reference  Index 
which  relates  Individual  events  and  their  NAIs  and  relates  the  NAIs 
to  Event  Templates  and  Snapshot  Templates. 
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3. 1.2. 3. 6  Target  Analysis  Matrixes 


For  Improved  efficiency  overall  the  IPB  analyst  builds  the  initial 
target  analysis  matrixes  with  a  minimum  degree  of  detail.  More  detailed 
modification  of  specific  matrixes  Is  performed  after  the  eneiny  Intentions 
have  been  perceived  and  the  Intelligence  Estimate  Is  made.  Figure  3.1.2-36 
diagrams  the  IPB  target  analysis  matrix  build  process.  Each  matrix  is 
associated  with  a  specific  event  template/matrix  and,  in  turn,  a  speci¬ 
fic  snapshot.  Therefore,  the  process  is  repeated  for  each  snapshot/event 
template  within  each  option. 

Since  targets  are  associated  by  location  and  time  with  events,  the 
first  step  in  the  build  process  Is  to  view  a  specific  event  template. 

The  IPB  analyst  selects  the  desired  event  template  from  the  file  and 
reviews  it  on  the  graphics  CRT.  Working  within  each  NAI  the  analyst 
notes  the  type  of  enemy  unit  and  the  activity  of  that  unit  portrayed 
on  the  event  template.  For  more  details  he  could  display  the  appropriate 
situation  templates  and/or  event  matrix. 

The  analyst  retrieves  the  doctrinal  target  menu  Identified  with 
the  specific  type  of  unit  or  activity.  He  selects  those  targets 
which  In  his  judgment  are  applicable  to  this  option  and  event.  The 
selection  action  (light  pen  or  keyboard  entry)  causes  the  system  to 
transfer  that  Item  to  a  working  file  used  to  build  the  target  analysis 
matrix.  The  TAI  Identification  Is  entered  by  the  analyst.  This  process 
is  repeated  for  each  type  of  unit  In  each  NAI  that  the  analyst  elects 
to  consider. 

At  this  point  the  working  file  has  a  set  of  potential  targets 
with  their  doctrinal  descriptions  and  the  TAIs  with  which  they  belong. 

The  analyst  can  review  the  list  In  a  skeletonized  target  analysis 
matrix  format  on  the  A/N  CRT. 
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Figure  3.1.2-36.  Function:  Target  Analysis  Matrix 
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To  relate  the  potential  targets  to  time  the  analyst  next  displays 
the  related  event  matrix  on  the  A/N  CRT.  Time  ranges  based  upon  snap¬ 
shot  time  were  assigned  to  each  event  listed.  These  same  events 
correspond  with  potential  targets  and  the  analyst  transfers  the  time 
estimates  to  the  potential  targets  in  the  target  analysis  matrix  working 
file.  The  updated  file  can  then  be  viewed  in  matrix  format  on  the  A/N 
CRT.  Figure  3.1.2-37  is  an  example  of  a  target  analysis  matrix.  Entries 
in  the  columns  vicinity,  worth  and  weapons  system  assignment  are  inten¬ 
tionally  not  made  at  this  time.  See  Section  3. 1.3. 3  for  completion  of 
these  elements  of  information. 

3. 1.2. 3. 7  Target  Templates 

Target  templates  are  built  initially  in  a  generalized  manner  for 
the  same  reasons  cited  for  target  analysis  matrixes.  Figure  3.1.2-38 
diagrams  the  building  of  one  target  template.  Each  template  is  associ¬ 
ated  with  a  specific  event  template  and  target  analysis  matrix  which 
in  turn  is  associated  with  a  specific  snapshot.  Therefore,  the  process 
Is  repeated  for  each  snapshot/event  template  within  each  option. 

For  an  enemy  option  the  IPB  analyst  selects  the  event  template 
for  the  time/area  under  consideration  and  reviews  it  on  the  graphic 
CRT.  He  also  queries,  retrieves  and  displays  on  the  A/N  terminal  the 
target  analysis  matrix  which  corresponds  to  that  event  template.  The 
remainder  of  the  build  function  Is  supported  by  the  subfunctions  of 
the  system  graphics  capabilities  by  which  Interactively  the  analyst 
changes  the  display  (event  template)  on  the  graphic  CRT.  Within  each 
NAI  circle  the  analyst  selects  a  military  unit  (flag  symbol),  notes  on 
the  A/N  CRT  what  targets  that  represents,  deletes  the  flag  symbol  and 
builds  the  appropriate  target  symbols  In  its  place.  Repeating  this 
process,  the  analyst  "plots"  the  targets  listed  on  the  target  analysis 
matrix  within  NAI  circles  on  a  map  background.  Upon  completion  of  the 
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Figure  3.1.2-37.  Target  Analysis  Matrix  Ezample 
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process  the  circles  are  TAIs  and  the  scene  on  the  graphics  CRT  is  the 
target  template.  The  analyst  annotates  It  as  desired,  indexes  and 
stores  It  on  a  working  file  for  later  use.  Figure  3.1.2-39  shows  the 
completed  target  template. 

A  representative  set  of  symbols  to  use  for  targets  Is  as  follows: 


TITLE/TARGET  TYPE 

SYMBOL 

NOTES 

Radar  Emitter 

(r 

•  • 

•  • 

•  • 

Each  symbol  displayed  represents 

Communications  Emitter 

one  or  a  prescribed  number  of 

eml tters 

Shooter-Artillery 

o 

Each  symbol  represents  one  or  a 

Shooter-Missile/Rocket 

£ 

prescribed  number  of  shooters 
(a  battery) 

Mover 

o 

Each  symbol  represents  1  to  10 

movers 

3. 1.2. 3. 8  Decision  Alternative  Templates 

For  each  predicted  enemy  course  of  action  (option)  one  or  more 
friendly  alternative  reactions  are  planned  for  the  contnander's  con¬ 
sideration.  The  graphic  summarization  of  the  enemy-friendly  actions 
Is  the  commander's  decision  support  template.  This  template  could  be 
developed  during  this  IPB  phase,  l.e.,  before  the  battle,  but  the 
process  Is  described  In  Section  3. 1.3. 3  of  the  IPB  Product  Use  section. 


3-115 


3-116 


!'i|[urr  Turuel  IVnif>l»l<-  I  xiiinplr 


One  of  the  essential  elements  to  be  Included  on  that  template  is  time 
available.  That  figure  is  not  determinable  until  the  IPB  Intelligence 
Estimate  has  predicted  in  which  option  and  where  in  that  option  the 
enemy  has  been  detected. 

Various  elements  supporting  the  commander's  decision  support  tem¬ 
plate,  called  decision  alternatives,  can  be  developed  in  this  IPB  phase 
however  depending  upon  the  specifics  of  the  situation.  Two  examples, 
maneuver  and  fires,  are  included  as  representative  of  the  decision 
alternative  process  and  graphics.  Early  preparation  facilitates  a 
more  rapid  update  during  the  battle. 

The  decision  alternative  templates  resemble  snapshots  very  closely, 
hence  the  first  step  of  the  function  diagrammed  in  Figure  3.1.2-40  is 
for  the  IPB  analyst  to  select  a  snapshot  based  upon  command  guidance. 

The  analyst  merges  the  snapshot  with  the  appropriate  map  background  and 
the  military  boundaries  of  both  enemy  and  friendly  forces.  The  friendly 
boundaries  used  Initially  are  as  in  the  current  situation.  Flag  symbols 
representing  enemy  forces  other  than  combat  units  are  deleted  by  the 
analyst  to  reduce  clutter. 

The  amount  of  IPB  support  to  the  development  of  the  maneuver 
decision  alternative  template  is  variable.  For  snapshots  which  occur 
very  early  in  the  enemy  option,  perhaps  well  prior  to  the  enemy  reaching 
the  line  of  contact  or  main  battle  area,  there  may  not  be  any  maneuver 
action  needed.  Hence,  the  friendly  portion  of  the  decision  alternative 
template  would  consist  of  the  current  maneuver  situation.  For  other 
snapshots  schemes  of  maneuver  may  be  planned.  Flag  symbols  represent¬ 
ing  combat  units  are  depicted  at  the  battalion  level.  The  combat  power 
ratio  algorithm  is  employed  by  the  IPB  analyst  to  determine  the  size  of 
the  enemy  force  In  the  selected  geographic  area  expressed  in  equivalent 
U.S.  maneuver  battalions.  Application  of  command  guidance  as  to  the 


Figure  3.1.2-40.  Function:  Decision  Alternative  Template  (Sheet  1  of  2) 


desirable  force  ratio  readily  translates  the  enerry  size  into  the 
friendly  force  size  which  should  be  used  in  the  particular  alternative 
envisioned.  The  IPB  analyst  uses  the  system  capabilities  of  drawing 
military  boundaries  and  building  flags  to  outline  the  areas  of  respon¬ 
sibility  and  build  the  desired  number  of  friendly  maneuver  units  on 
the  graphics  display. 

Questions  of  maneuver  feasibility  and  careful  determination  of 
friendly  force  locations  is  purposely  postponed  for  consideration 
during  the  real  time  battle  situation.  Hence,  this  subfunction  ends 
with  having  developed  a  planned  maneuver  decision  alternative  template 
for  the  selected  snapshot  in  which  the  friendly  units  have  been  "sized" 
to  meet  the  planned  enemy  force,  but  have  not  been  carefully  located 
on  the  terrain  and  have  not  been  tested  for  feasibility  of  getting 
into  position.  Figure  3.1.2-41  is  an  example  of  a  maneuver  decision 

alternative  template.  This  template  is  indexed  and  stored  in  a  work  file 
for  later  retrieval  and  use.  The  process  is  repeated  for  each  snap¬ 
shot,  each  option  as  desired. 

The  other  decision  alternative  diagrammed  in  the  functional  flow 
chart  is  the  preparation  of  the  fire  support  portion  of  the  decision 
alternative  template.  In  the  case  of  early  snapshots  where  no  specif'c 
scheme  of  maneuver  is  involved,  interdiction  of  the  enemy  may  be  the 
primary  action  to  be  taken.  Hence,  the  fire  support  portion  may  be  the 
most  significant.  In  any  case,  the  fires  function  also  uses  command 
guidance  as  input  parameters  in  addition  to  the  G-3  maneuver  plan(s). 

The  same  snapshot(s)  selected  In  the  previous  subfunction  is  used  as 
a  basis  for  selecting  the  corresponding  target  template  from  the  files, 
merging  it  with  the  appropriate  map  backgrounds  and  military  boundaries 
from  the  current  situation.  Concurrently,  the  analyst  queries  the 
A/N  data  base  to  display  the  corresponding  target  analysis  matrix. 
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Figure  3.1.2-41  Maneuver  Decision  Alternative  Template  Example 


The  remainder  of  the  subfunction  Is  similar  to  that  of  the  maneuver 
portion,  l.e.,  contingent  upon  a  decision  to  retain  the  current 
allocation/assignment  of  FA  units  or  to  change  it.  If  the  former, 
the  current  plot  of  FA  battalions  Is  merged  on  the  graphic  display. 

If  the  latter,  the  build  flag  capability  is  used  to  build  a  planned 
fires  decision  alternative  template  based  upon  definition  of  the 
optimum  number  of  FA  battalions  required  to  service  the  number  of 
targets.  This  template  is  also  indexed  and  stored  for  possible  later 
retrieval  and  update  in  more  detailed  fashion.  Again,  the  process  is 
repeated  for  each  snapshot  within  each  option  as  required. 

3.1.3  IPB  Product  Use  Functions 


This  section  describes  the  use  of  IPB  products  in  the  course  of 
hostilities.  HIPO  diagrams  are  used  to  describe  the  IPB  support  pro¬ 
vided  to  the  following  command  and  control  functions: 

t  Intelligence  Functions  including  Intelligence  Estimates 

•  Maneuver  and  Fires  Operations  Planning 

•  Commander's  Decision  Support 

3. 1.3.1  Intelligence  Functions  Support 

Figure  3. 1.3-1  is  a  diagram  showing  the  way  the  IPB  analyst  uses 
pre-built  IPB  products  in  performing  his  realtime  intelligence  esti¬ 
mating  function  and  to  focus  collection  resources  on  higher  yield  areas 
of  interest. 
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Figure  3. 1.3-1.  Operational  Concept 


In  the  upper  right  corner  of  the  diagram  are  a  group  of  2  blocks 

indicating  that  the  IPB  analyst  receives  frequent  updates  to  the  current 

military  situation  picture.  This  picture  shows  enemy  locations  and 
movements  at  the  unit  level  and  is  displayed  at  the  IPB  station  on  a 
separate  monitor.  The  IPB  analyst  can  cause  a  situation  update  to 
appear  on  his  current  situation  monitor,  and  can  cause  it  to  be  scaled 
to  match  his  IPB  products.  Generation  of  this  display  through  corre¬ 
lation  and  fusion  processes  is  assumed  to  be  a  continuous  process 
performed  by  an  ASAS  function  external  to  the  IPB  function. 

When  he  receives  a  current  situation  update,  he  will  normally 

position  the  cursor  (on  the  IPB  graphic  monitor)  close  to  a  newly 

reported  activity  of  interest  and  ask  the  system  to  display  on  the 
alphanumeric  screen,  a  list  of  all  prestored  situation  templates 
which  contain  the  identified  point.  He  compares  prestored  situation 
templates  with  similarly  scaled  areas  on  the  current  situation  screen. 

He  looks  for  approximate  matches,  relying  on  his  experience  and  fami¬ 
liarity  with  templates  and  parent  snapshots  previously  built.  He  will 
frequently  draw  on  his  other  IPB  files  (doctrinal  templates,  terrain 
overlays,  technical  data,  etc.)  to  try  to  rationalize  differences  in 
the  situation  displays.  He  repeats  this  process  as  further  updates 
are  received.  He  is  continuously  attempting  to  isolate  the  enemy 
option  and  snapshot  point.  When  he  believes  he  has  identified  an 
option  and  snapshot  he  attempts  to  confirm  his  hypothesis.  He  does 
this  by  requesting  Intelligence  collections  against  the  pre-planned 
event  matrix  and  event  template  following  the  selected  snapshot  point. 

He  cues  the  input  processing  system  to  inmediately  route  alert  messages 
to  his  alphanumeric  screen  when  sensor  returns  for  specific  collection 
requests  are  received. 
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The  input  process  system  also  signals  the  analyst  after  a  pre¬ 
scribed  time  if  none  of  the  event  matrix  events  are  detected.  This 
allows  him  to  terminate  collection  and  front  end  conditioning  if  he 
chooses . 

At  a  point  when,  in  his  judgment,  a  sufficient  number  of  events 
have  been  identified  as  fitting  the  event  matrix,  the  analyst  may 
choose  to  declare  the  option  and  snapshot  point  confirmed.  He  then 
analyzes  additional  snapshots  that  occur  far  enough  in  the  future  in 
the  option  so  that  friendly  actions  can  be  taken  to  adequately  defend 
the  attack.  He  may  need  to  update  the  snapshots  to  reflect  current 
situation,  e.g.,  different  unit  locations  or  force  composition.  Once 
satisfied  that  the  snapshot  reflects  the  bee  st  portrayal  of  enemy 
intentions,  the  analyst  uses  it  as  his  "intelligence  estimate."  He 
prepares  data  on  two  or  more  future  snapshots  as  a  briefinq  tool  for 
the  G-3  staff  and  commander. 

In  concert  with  the  G3  operations  staff,  he  prepares  alternative 
decision  support  templates.  These  show  required  and  achievable 
friendly  force  movements  and  tlminqs  to  defend  at  successive  phase 
lines.  These  will  reflect  the  results  of  analysis  which  trades  off 
achievable  combat  power  ratios  against  such  considerations  as  best 
terrain  for  defense. 

In  addition,  event  templates  can  be  exploited  to  notify  the  Fire 
Support  Element  (FSE)  of  what  targets  can  be  expected  at  which  locations 
over  the  next  several  hours.  Preplanned  operations  orders  can  be 
finalized  for  deployment  of  friendly  forces  to  meet  the  enemy.  The 
terrain  analyses  completed  In  advance  by  the  G2  staff  would  be  useful 
to  the  FSE  and  maneuver  sections  in  planning  fires  allocation  and 
friendly  force  movements  to  interdict. 
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3. 1.3. 1.1  IPB  Temp late/ Current  Situation  Comparison  Process 

Figure  3. 1.3-2  indicates  the  inputs,  processes  and  outputs  of 
the  IPB  Template/Current  Situation  Comparison  processing  subfunction. 

This  subfunction  shall  provide  automation  support  to  the  IPB  analyst 
as  he  performs  his  IPB  analysis  during  hostilities  to  arrive  at  the 
intelligence  estimate  of  the  situation. 

The  IPB  analyst  controls  the  call-up  and  display  of  new  scenes 
on  his  current  situation  screen.  He  closely  monitors  enemy  forces  and 
areas  of  interest.  He  continuously  looks  for  significant  indicators 
of  new  enemy  options  and  courses  of  action.  When  a  new  situation 
report(s)  comes  to  his  attention,  he  positions  the  graphic  cursor  to 
a  central  point  in  the  interest  area  and  queries  the  system  to  provide 
him  a  Situation  Template  List.  Search  shall  be  against  an  index  of  all 
stored  situation  templates-,  It  retrieves  all  situation  templates  which 
contain  the  cursor  Indicated  point.  The  list  is  displayed  on  his 
alphameric  screen. 

The  analyst  selects  one  situation  template  for  call-up  and  display 
on  his  IPB  screen.  The  scale  is  selected  by  the  analyst  and  will  normally 
be  1:50,000.  As  he  calls  this  situation  template,  the  system  will  read 
the  template's  centerpolnt  (Included  in  the  record).  Using  this  and  the 
template  scale  value,  the  system  will  cause  the  corresponding  field  of 
view  and  scale  of  the  current  situation  screen  to  be  displayed. 

The  analyst  visually  compares  the  content  of  the  two  screens, 
attempting  to  Identify  close  matches.  He  augments  this  step  by  calling 
other  IPB  products- -snapshots,  doctrinal  templates,  planned  routes, 
mobility  corridors,  terrain  subfactors  and  composites --to  his  IPB  screen 
to  help  rationalize  differences  between  the  template  and  current  situation 
graphic. 
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Figure  3. 1.3-2.  Current  Situation  Compare  Function 

(Sheet  1  of  2) 
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Figure  3. 1.3-2.  Current  Situation  Compare  Function 
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He  proceeds  to  the  next  situation  template  on  the  list.  This  is 
called  up  on  the  graphic;  the  current  situation  screen  field  of  view 
and  scale  are  adjusted  and  the  comparison  process  using  augmenting  IPB 
products  is  repeated.  If  a  strong  match  is  found  between  one  situation 
template  and  a  unit  activity  on  the  current  situation  screen  and  the 
analyst  has  progressed  far  enough  in  his  investigation  of  options,  he 
may  elect  to  move  on  to  the  next  phases  of  the  IPB  process.  In  some 
cases  the  analyst  may  become  convinced  that  there  is  good  correspondence 
between  a  situation  template/snapshot  and  a  current  situation  activity 
although  the  match  he  finds  is  a  partial  rather  a  strong  match.  In 
this  case  he  will  update  the  parent  snapshot  as  diagrammed  on  paqe  2 
of  the  Figure  3. 1.3-2.  He  merges  overlays  including  the  current  situ¬ 
ation  and  doctrinal  templates  on  top  of  the  planned  snapshot  (he  may 
also  work  with  situation  templates  if  expanded  detail  is  required). 

He  adjusts  unit  locations  to  better  fit  the  current  situation  activity; 
he  deletes  overlays,  adds  annotation  and  stores  the  updated  snapshot. 

The  updated  version  shall  be  stored  as  an  additional  snapshot  and  not 
cause  deletion  of  the  original  snapshot.  By  maintaining  a  record  of 
changes  in  this  manner,  the  analyst  will  have  valid,  updated  snapshots 
for  quick  reference  when  he  subsequently  develops  the  intelligence 
estimate. 

If  no  strong  matches  are  found  between  templates  on  the  situation 
template  list  and  the  unit  activity/area  of  interest  on  the  current 
situation  screen,  the  analyst  has  several  choices.  He  may  return  to 
the  master  large  area  current  situation  graphic  and  select  another 
activity/area  for  focuslnq  his  attention.  Or,  if  he  has  thoroughly 
analyzed  all  the  latest  units/activities  on  the  current  situation 
graphic  without  resolving  between  options,  he  may  elect  to  await  the 
next  update  to  be  routed  to  him  by  the  current  situation  analyst. 
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While  engaged  in  this  search/template  match  process,  he  may  elect 
to  call  particular  snapshots  that  will  be  helpful  in  checking  overall 
timing  of  perceived  enemy  movements.  By  referencing  particular  snap¬ 
shots,  he  may  gain  confidence  that  an  enemy  force  has  not  progressed 
beyond  a  certain  phase,  even  though  he  may  not  have  high  confidence 
of  what  option/course  of  action  the  enemy  is  embarked  on. 

Control  of  Slaved  Current  Situation  Graphic  Monitor 


This  monitor,  located  at  the  IPB  analyst  position,  is  slaved  to  a 
master  current  situation  terminal  which  is  operated  external  to  the  IPB 
process.  These  paragraphs  describe  the  software  functions  and  controls 
relevant  to  the  IPB  analyst's  use  of  the  slaved  monitor  in  the  comparison 
process. 

In  its  standby  mode,  a  copy  of  the  last  declared  current  situation 
graphic  shall  be  displayed  on  the  slaved  monitor  for  viewing  by  the 
IPB  analyst. 

At  the  time  of  a  new  update  to  the  master  current  situation  graphic, 
a  prominently  blinking  message  "UPDATE"  shall  be  displayed  in  the  upper 
left  corner  of  the  slaved  monitor.  This  message  will  overlay  whatever 
scene  is  then  displayed  and  not  cause  deletion  of  that  scene. 

Upon  IPB  analyst  action,  the  newly  declared  current  situation 
graphic  from  the  master  terminal  shall  be  displayed  in  its  entirety  on 
the  slaved  screen,  automatically  causing  deletion  of  the  previously 
displayed  scene. 
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Upon  IPB  analyst  action,  a  center  point  for  a  new,  expanded  field 
of  view  shall  be  Identified  and  the  new,  expanded  scale  view  shall  be 
displayed  on  the  slaved  monitor.  Center  point  identification  shall  be 
by  graphic  cursor  control  on  the  IPB  template  graphic  screen  (not  on 
the  slaved  current  situation  screen).  Scale  of  the  expanded  view  shall 
be  selected  by  function  key  input  at  the  IPB  analyst  console.  The 
expanded  scene  shall  contain  all  symbols,  vectors  and  notation  from 
the  portion  of  the  parent  current  situation  graphic  presented  in  the 
new  view.  s 

Other  controls  required  by  the  IPB  analyst  include  the  ability  to 
selectively  display  part  or  all  of  the  current  situation  directly  on 
the  IPB  graphic  screen.  This  capability  is  required  to  support  the 
IPB  product  build  functions  and  is  further  discussed  in  Section  3.1.2. 

3. 1.3. 1.2  Collections  Tasking/Monitoring 

Figure  3. 1.3-3  Indicates  the  Inputs,  processes  and  outputs  of 
the  IPB  Collections  Tasking/Monitoring  processing  subfunction.  This 
subfunction  shall  provide  automation  support  to  the  IPB  analyst  as  he 
makes  sensor  tasking  requests  and  processes  returns  from  sensor 
collections. 

The  IPB  analyst  controls  the  flow  of  the  collections  tasking 
request/monitoring  activity.  As  part  of  the  IPB  planning  process 
prior  to  hostilities  he  has  planned  a  series  of  Event  Templates  and 
Event  Matrixes  and  provided  copies  of  these  to  the  Collections 
Management  function.  During  hostilities,  he  uses  Event  Templates  and 
Event  Matrix  Lists,  updated  to  reflect  real  time  projections  of  enemy 
courses  of  action,  as  a  means  of  focusing  sensor  collection  assets  to 
acquire  critical  Indicator  Information  and  thereby  to  help  confirm  what 
option/course  of  action  the  enemy  is  following.  The  analyst  receives 
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Intelligence  reports  that  are  In  response  to  his  requests.  He  and/or 
the  system  post  analyzed  results  to  an  Event  Matrix  Status  Summary. 
When,  in  his  judgment,  a  sufficient  number  of  events  closely  matching 
a  preplanned  set  have  been  detected  he  declares  an  option/course  of 
action  as  confirmed  and  proceeds  to  the  next  IPB  phase  which  is 
development  of  the  Intelligence  Estimate. 

Collections  Tasking 

Referring  to  Figure  3. 1.3-3,  the  analyst  first  calls  the  Event 
Matrix  Index  to  his  tabular  screen;  he  selects  the  planned  Event 
Matrix  for  which  he  has  decided  to  invoke  a  collections  tasking 
request.  The  corresponding  Event  Template  shall  be  automatically 
displayed  on  the  graphic  screen.  This  combination  of  graphic  and 
tabular  data  provides  the  analyst  with  critical  events/indicators 
that  doctrinally  should  follow  closely  after  the  related  snapshot 
point. 

The  analyst  updates  the  Event  Template  and  Event  Matrix  to 
reflect  real  time  changes  to  planned  events  as  a  result  of  comparisons 
and  analysis.  Changes  to  graphic  symbols  shall  be  via  function  key¬ 
board  and  graphic  cursor.  Changes  to  tabular  entries  shall  be  via  the 
typewriter  keyboard. 

The  analyst  then  calls  the  Collections  Tasking  Request  Message 
Format  which  shall  be  displayed  on  the  tabular  screen.  Selection  of 
this  message  format  shall  be  via  a  tabular  menu  and  lightpen  or 
similar  data  entry  device.  Upon  analyst  action  the  desired  content 
of  the  Collections  Tasking  Request  message  shall  be  completed  by  a 
flll-ln-the-blanks  technique.  He  may  elect  to  include  all  or  part  of 
the  plannea  matrix  In  the  collection  message.  If  no  changes  are 
required  to  the  planned  event  set,  he  may  prepare  an  abbreviated 
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message  simply  referencing  the  planned  Event  Matrix/Event  Template 
pair  that  was  provided  to  the  Collections  Management  function  prior 
to  hostilities.  The  completed  message  Is  transmitted  to  the  Collec¬ 
tions  Management  function. 

Collections  Monitoring 

Referring  to  page  2  of  Figure  3. 1.3-3,  an  IPB  input  processing 
function  automatically  monitors  intelligence  reports  incoming  to  the 
IPB  system.  When  an  event  number  requested  by  the  IPB  analyst  is 
detected,  the  system  generates  an  alert  message  which  is  automatically 
displayed  on  the  tabular  screen.  The  alert  message  shall  be  super¬ 
imposed  on  whatever  tabular  message  is  then  displayed  on  the  tabular 
screen;  it  shall  not  cause  automatic  deletion  of  the  existing  screen 
contents . 

Upon  analyst  action  the  intelligence  report  containing  the 
requested  information  shall  be  automatically  composed  and  displayed 
on  the  tabular  screen.  The  updated  current  situation  shall  be 
simultaneously  displayed  on  the  graphic  monitor. 

The  analyst  then  calls  the  Event  Matrix  Status  Summary  corre¬ 
sponding  to  the  appropriate  Event  Matrix  for  display  on  the  tabular 
screen.  Location  and  time  of  the  event  shall  be  entered.  Upon 
analyst  action  the  updated  Event  Matrix  Status  Summary  shall  be  stored 
with  the  new  event  detection  data  filled  in. 
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3. 1.3. 1.3  Intelligence  Estimate  Development 


Figure  3. 1.3-4  indicates  the  inputs,  processes  and  outputs  of  the 
IPB  Intelligence  Estimate  Development  processing  subfunction.  This  sub¬ 
function  shall  provide  automation  support  to  the  IPB  analyst  as  he 
prepares  the  G-2  intelligence  estimate  of  the  situation  which  he  will 
use  to  brief  the  commander  and  G-3  staff. 

The  IPB  analyst  having  gained  sufficient  confidence  that  he  knows 
the  option  and  snapshot  that  the  enemy  is  in,  next  prepares  the  intelli¬ 
gence  estimate  of  the  situation.  The  analyst  begins  by  assessing  the 
validity  of  his  pre-hostility  IPB  products  for  the  confirmed  option. 

He  does  this  by  examining  the  snapshots  and  situation  templates  which 
reflect  the  early  stages  in  the  option.  He  decides  whether  the  differ¬ 
ences  between  pre-built  template  data  and  current  situation  data  that 
he  noted  and  recorded  on  these  templates  during  the  comparison  process 
signify  an  impact  due  to  force  size/composition  changes  and/or  weather 
changes.  If  not,  the  analyst  bypasses  the  next  few  steps  on  the  dia¬ 
gram  and  proceeds  to  the  pra-built  Snapshot  Lines  Template.  If  yes, 
the  analyst  calls  the  Planned  Routes  Template  for  the  option.  He 
determines  which  map  areas/pre-built  corridors  are  affected  and 
therefore  will  require  re-examination. 

He  now  re-evaluates  the  enemy's  choice  of  routes,  corridors,  attack 
formations  and  overall  route  timings.  He  does  this  by  calling  to  the 
graphic  screen  one  at  a  time,  the  pre-built  crosscountry  and  road  corri¬ 
dors.  Using  algorithmic  techniques  described  elsewhere  in  this  document, 
he  causes  corridor  rating  and  transit  time  for  each  corridor  to  be 
recomputed.  He  transfers  the  accumulated  times  to  the  Snapshot  Lines 
Template  thus  arriving  at  a  revised  total  time  between  the  snapshot 
point  at  which  the  option  is  confirmed  and  the  attack  line  snapshot 
point. 
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Figure  3. 1.3-4.  Intelligence  Estimate  Development  Function  (Sheet  1  of  3) 
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Intelligence  Estimate  Development  Function  (Sheet  3  of  3) 


He  next  updates  the  pre-built  Attack  Line  Snapshot  Template  which 
together  with  the  Snapshot  Lines  Template  will  constitute  the  basis  of 
the  intelligence  estimate.  To  update  this  template,  he  may  use  a  variety 
of  merged  overlays  as  indicated  by  the  diagram.  He  may  superimpose  on 
the  graphic  screen  at  one  time,  the  pre-built  snapshot,  the  mobility 
corridors  overlay,  and  groups  of  symbols  that  are  cursor  designated  to 
be  transferred  from  the  current  situation  monitor.  Superimposed  on  this 
working  display,  he  locates  and  orients  a  doctrinal  template.  He  then 
adjusts  the  positions  of  individual  symbols  making  up  the  snapshot.  If 
a  difference  in  force  size/composition  is  indicated,  he  adds  or  deletes 
or  modifies  symbols.  If  a  difference  in  corridors  is  indicated,  he 
relocates  individual  symbols  or  groups  of  symbols  to  suit  his  inter¬ 
pretation  of  enemy  doctrine  fitted  to  the  terrain  and  weather. 

The  analyst  adjusts  pertinent  military  data  including  attack  line, 
line  of  contact,  phase  lines  and  military  boundaries.  He  causes  the 
corridor,  doctrinal  template  and  current  situation  overlays  to  be 
deleted,  leaving  the  updated  snapshot  information  on  the  working  display. 

When  satisfied  with  the  template  picture  including  the  second 
echelon  projected  and  first  echelon  existing  forces,  the  analyst 
annotates  the  graphic  to  Include  expected  attack  time,  total  force 
size  and  direction  of  attack.  He  adds  an  identifying  number  and  time 
stamp  and  stores  the  product  in  the  system  permanent  file.  The  system 
automatically  updates  its  indexes  to  reflect  this  item. 

The  analyst  may  repeat  this  process  for  another  snapshot  of  this 
same  option.  The  purpose  would  be  to  provide  the  G-3  maneuvers  analyst 
with  an  alternate  line  at  which  to  plan  a  main  defense. 
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3. 1.3. 2  Operations  Functions  Support 


IPB  products  are  also  useful  in  supporting  some  of  the  functions 
which  are  the  responsibility  of  the  G-3  staff.  G-3  product  use  during 
hostilities  generally  beqins  with  the  G-2's  prediction  of  the  enemy's 
probable  corridors  of  advance,  attack  locations,  force  sizes,  and  time 
of  attack.  The  G-3  support  functions  are  oriented  toward  using  IPB 
data  to  determine  feasibility  of  maneuver  actions  in  response  to  the 
predicted  enemy  movement.  Such  functions  may  well  be  incorporated 
Into  systems  other  than  the  ASAS.  However,  the  use  of  basic  IPB  data 
(provided  by  the  ASAS)  would  be  of  value  in  several  G-3  activities. 

The  IPB  products  which  may  be  used  by  the  G-3  staff  Include: 

•  Terrain  composite  overlays 

CCM 

COM 

Mobility  corridors 
Intervisibility  corridors 

•  Weather  Overlays 

•  IPB  Template  Products 

Snapshots 

Situation  Templates 
Target  Analysis  Matrixes 
Target  Templates 

"Best"  Decision  Alternative  Templates 

•  Special  Processes 

Corridor  Rating/Painting 
Route  Timing 
Combat  Power  Ratio 
Symbol  Matching 
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Extracts  from  the  Current  Situation  (both  ENSIT  and  FRENSIT)  graphics 
as  well  as  A/N  data  base  are  essential  in  supporting  G-3. 

The  objective  of  the  use  of  IPB  products  is  to  facilitate  the 
efforts  of  the  Maneuvers  Section  and  the  Fire  Support  Element  of  the 
TOC  to  develop  feasible,  alternative  courses  of  action  which  can  be 
presented  to  the  commander  for  decision  and  then  implementation. 

Section  3. 1.3. 2.1  explains  IPB  support  to  the  maneuver  planning  and 
Section  3. 1.3. 2. 2  support  to  fires  planning. 

3. 1.3. 2.1  Maneuver  Planning 

The  IPB  products  used  in  this  function  are: 

•  Templates 

Snapshots 

Decision  Alternative 
Terrain  and  Intervi slbil ity 

•  Special  Algorithms 

Route  Timing 
Symbol  Matching 
Combat  Power  Ratio 
Symbol  Replot 

Intervisibility  Corridor  Paint  and  Rate 

A  detailed  presentation  of  how  IPB  products  are  used  to  support 
maneuver  planning  Is  contained  In  Figure  3. 1.3-5.  Feasible  (or  achiev¬ 
able)  alternatives  can  be  developed  rapidly  by  analyst  interaction  with 
IPB.  Once  the  Intelligence  Estimate  Is  made  and  the  enemy  option  (course 
of  action)  Identified,  the  major  factor  governing  friendly  force  reaction 
Is  time  available.  The  analyst  can  select  the  predicted  enemy  disposition 
using  the  snapshot  line  display  which  identifies  snapshots  and  time 
Intervals.  The  analyst  selects  the  pre-prepared  "best"  or  "optimum" 
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Figure  3. 1.3-5.  Maneuver  Planning  Function  (Sheet  1  of  5) 


3-138 


function 


OUTPUT 


4  1:290.000 
Sal# 

•  MlllUry 


■1 


CHECK  NEW  POSITIONS 


•  Unmatched  -test 
IN  Current 
Nweuver  Battalions 


POSITION 

1  cursor 


SELECT  AREA 
OF  UWMTCHEO 
UNITS 


SCALE 

(EXPAND  AREA) 


•  Visually 

i  REVIEW  “BEST"  I  Determine 

I  MANEUVER  UNIT  r+ - 

POSITIONS 

- - - - • 


ADJUST  AMY 

*  T  ** 


MOVE 

SVMKXS/ FLAGS 


MORE  OETAIL 


•  1:90.000  Seal# 

•  Military 
Boundaries 

e  Unmatched 
Maneuver 
Battalions 


e  1:90.000  Scale 
e  Nap 

0  Military 
Boundaries 

e  Unmatched 
Maneuver 
Battalions 
e  CCN  (or  other 
terrain  sub- 
factor  overlays) 


|m  .  ;  ■] 


0  1:90.000  Scale 

e  Unmatched 
Maneuver 
Battalions 
e  Intervts. 
Overlay 


Figure  3. 1.3-5.  Maneuver  Planning  Function  (Sheet  2  of  5) 
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Figure  3. 1.3-5.  Maneuver  Planning  Function  (Sheet  3  of  5) 
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maneuver*  decision  alternative  template  (Section  3. 1.2. 3. 8).  By  using 
the  symbol  matching  algorithm  the  analyst  tests  the  general  location  of 
the  desired  number  of  maneuver  battalions  with  the  current  FRENSIT  to 
determine  which  desired  positions  are  already  fulfilled  by  existing 
maneuver  battalions,  which  desired  positions  can  be  fulfilled  only  by 
moving  a  battalion  from  its  present  location  and  which  battalions  are 
"available"  to  be  relocated.  Note,  that  the  two  displays  use  different 
colors  for  friendly  unit  symbols,  e.g.,  blue  for  current,  cyan  for  "best" 
to  facilitate  visual  comparison.  This  technique  rapidly  establishes  the 
movement  feasibility  issue:  Can  we  get  from  here  to  there  in  the  time 
available?. 

Prior  to  testing  that  feasibility,  the  analyst  verifies  the  suit¬ 
ability  of  the  desired  position.  IPB  CCM,  Slope  and  Vegetation  as  well 
as  LOC  overlays  are  used  to  make  this  check.  Adjustments  to  positions, 
if  desired,  can  be  readily  accomplished  using  IPB  graphics  functions. 
Suitability  of  proposed  positions  is  also  checked  with  regard  to 
intervisibility. 

Movement  feasibility  is  then  ascertained  by  using  the  IPB  Route 
Timing  algorithm.  The  route  from  the  current  location  of  a  maneuver 
battalion  to  one  (or  more)  proposed  locations  is  traced  and  the  cumu¬ 
lative  movement  time  is  automatically  computed  and  displayed.  The  analyst 
must  add  other  (non-travel)  times  to  this  figure  and  compare  the  total 
to  the  time  available.  Depending  upon  his  judgement  that  a  unit  can  be 
moved  to  its  new  location  in  time,  the  analyst  continues  to  seek  to 
accomplish  the  planned  friendly  maneuver  force  disposition  to  meet  thp 
expected  enemy  action.  Each  of  the  detailed  1:50,000  scale  resulting 
graphics  are  stored  for  later  use. 

Next,  the  analyst  reconstructs  the  1:250,000  scale  maneuver  decision 
alternative  templates,  changing  from  a  planned  to  an  achievable  display. 

To  do  this  the  special  graphics  function  "Symbol  Replot"  is  required. 


3-139 


On  each  of  the  1:50,000  scale  displays  on  which  the  analyst  worked  out 
achievable  future/probable  locations  for  maneuver  units  he  identifies 
those  locations  and  types  of  units  by  invoking  Symbol  Replot  and 
positioning  the  cursor  at  each  location  to  be  saved.  The  symbol  dis¬ 
play  data  and  UTM  coordinates  are  automatically  stored.  After  doing 
this  operation  for  each  1:50,000  scene  the  analyst  completes  the  symbol 
replot  by  first  calling  the  "best"  planned  maneuver  alternative  and 
merging  the  achievable  maneuver  locations  on  the  1:250,000  scale  display. 
He  then  adjusts  the  graphics  display  by  eliminating  planned  positions 
which  have  been  modified  to  be  achievable  and/or  changing  color/blinking 
planned  position  symbols  which  cannot  be  achieved.  The  completed  scene 
is  re-titled  "achievable"  and  stored  for  later  reference. 

The  analyst  then  checks  the  maneuver  plan— the  achievable 
template— for  suitability,  i.e..  Does  it  provide  for  an  acceptable 
combat  power  ratio?  The  analyst  invokes  the  Combat  Power  Ratio  algorithm 
by  defining  the  area  of  interest.  The  ratio  appears  on  the  A/N  CRT. 

The  analyst  then  is  either  satisfied  that  he  would  present  this  plan  to 
the  commander  as  a  viable  alternative  course  of  action  or  he  discards 
It.  Other  alternatives  can  be  prepared  in  like  manner  by  repeating  the 
process  with  a  different  decision  alternative  template. 

3. 1.3. 2. 2  Fires  Planning 

IPB  products  used  in  conjunction  with  the  current  situation  display 
to  support  this  function  include: 

•  Target  Analysis  Matrixes 

e  Fires  Decision  Alternative  Templates 

•  Target  Templates 

•  Terrain  and  Intervisibility  Overlays 
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•  Special  Algorithms 
Route  Timing 

Intervlsiblllty  Corridor  Paint  and  Rate 

A  detailed  presentation  of  how  IPB  products  are  used  In  fires 
support  planning  Is  contained  In  Figure  3. 1.3-6.  Feasible  fires 
planning  in  support  of  the  alternative  maneuver  courses  of  action  can  be 
accomplished  rapidly  by  the  analyst  using  IPB  products.  The  starting 
point  depends  upon  Commander/G-3  guidance.  If  the  analysis  performed  in 
Section  3. 1.3. 2.1,  Maneuver  Planning,  Indicates  that  Insufficient  time 
Is  available  for  friendly  reaction,  and  diversion  of  enemy  operation  is 
advisable,  fires  planning  may  begin  at  an  earlier  snapshot  point  than 
the  maneuver  plan.  For  example,  G-3  may  want  to  interdict  the  enemy 
to  slow  the  advance  or  cause  a  change  to  the  enemy  route.  Based  upon 
guidance  the  analyst  selects  a  specific  maneuver  decision  alternative 
template  and  the  corresponding  target  analysis  matrix  to  update.  The 
analyst  calls  and  displays  the  corresponding  target  template  which 
provides  a  display  of  probable  targets  and  is  used  in  conjunction  with 
the  matrix.  The  analyst  selects  a  value  for  the  "worth"  of  each  target 
using  guidance  received  and  his  professional  judgement.  Suggested 
values  of  target  worth  are: 

10  *  vital  (Analogous  to  Priority  I  per  FM  6-20) 

20  3  important  (Analogous  to  Priority  II  per  FM  6-20) 

30  ■  supporting  (Analogous  to  Priorities  III  and  IV  per  FM  6-20) 

40  3  not  part  of  the  operation 
50  3  unimportant 

Each  definition  refers  to  the  relative  Importance  to  the  enemy  in  terms 
of  the  success  of  his  operation.  The  target  analysis  matrix  Is  updated 
via  the  alpnanumeric  keyboard. 
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Figure  3. 1.3-6.  Fires  Planning  Function  (Sheet  1  of  3) 


Using  knowledge  of  the  characteristics  of  the  targets  listed  and 
their  range  as  viewed  on  the  target  template  the  analyst  makes  a  decision 
as  to  weapons  systems  to  assign,  i.e. ,  close  air  support  or  field  artil¬ 
lery.  He  may  also  apply  commander's  guidance  to  indicate,  for  example, 
that  an  emitter  target  is  to  be  jammed  rather  than  destroyed.  Again, 
using  the  A/N  keyboard  the  analyst  completes  this  column  of  the  target 
analysis  matrix.  The  analyst  also  completes  the  vicinity  column  of  the 
target  analysis  matrix  by  employing  the  graphics  function  "UTM"— the 
UTM  coordinates  of  the  cursor  appear  in  the  lower  left  corner  of  the 
graphics  CRT.  By  successive  cursor  positioning  on  any  of  the  targets 
applicable  and  typing  the  corresponding  coordinates  on  the  A/N  keyboard 
the  vicinity  of  each  target  is  entered  in  the  matrix.  Figure  3. 1.3-7 
is  an  example  of  a  completed  target  analysis  matrix.  A  copy  of  the 
matrix  would  be  transmitted  to  the  collection  resources  manager,  and 
other  sections  of  G-2  and  G-3. 

With  the  updated  matrix  still  on  the  A/N  CRT,  the  analyst  calls  up 
the  "best"  or  optimum  fires  decision  alternative  template  previously 
prepared.  Since  specific  judgements  have  now  been  made  regarding  weapons 
systems  assignments  and  maneuver  planning,  more  specific  fire  support 
planning  may  be  accomplished.  A  new  determination  as  to  FA  support 
required  to  service  the  target  array  to  be  assigned  to  FA  attack  is 
used  to  modify  the  allocation  of  FA  battalions.  The  IPB  capability  to 
move,  add,  delete  flags  and  symbols  enables  the  analyst  to  quickly 
update  the  template. 

Once  a  quantitative  decision  has  been  reflected  on  the  graphics 
CRT,  the  analyst  is  ready  to  review  possible,  suitable  artillery 
battalion  locations.  IPB  products  such  as  terrain  subfactor  overlays, 
intervisibility  overlays  and  corridors  facilitate  this  process.  It 
must  be  emphasized  that  the  analyst  is  not  attempting  to  perform  a 
responsibility  normally  the  prerogative  of  the  unit  commander  in  the 
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Figure  3. 1.3-7.  Completed  Target  Analysis  Matrix 


field.  A  gross  feasibility  check  is  advantageous,  however.  Time  may 
be  saved  by  general  Indication  of  suitable  areas  for  the  FA  unit 
commander  to  do  a  more  detailed  survey.  As  shown  in  the  subfunction 
"Check  FA  Bn  Positioning"  the  analyst  uses  IPB  to  perform  a  gross 
search  with  respect  to  slope,  vegetation,  accessibility  by  suitable 
LOC  and  intervisibility.  The  graphics  plot  is  modified  as  necessary 
until  each  area  of  concern  has  been  reviewed. 

The  last  step  is  similar  to  that  used  In  maneuver  planning  wherein 
the  1:50,000  scale  detailed  plots  of  appropriate  locations  for  FA 
battalions  are  replotted  on  a  1:250,000  scale  display.  The  special 
graphics  function  Symbol  Replot  is  used  to  support  this  step.  The 
result  is  an  achievable  fires  decision  alternative  template.  Other 
alternatives  can  be  prepared  in  like  manner  by  repeating  the  process 
with  a  different  achievable  maneuver  decision  alternative  template. 

3. 1.3. 3  Commander's  Decision  Support 

The  decision  support  template  is  a  graphic  portrayal  of  probable 
enemy  courses  of  action  and  corresponding  friendly  courses  of  action. 

The  purpose  of  decision  support  templates  is  to  present  alternatives 
to  the  commander  in  a  manner  which  facilitates  comparison  of  advantages 
and  disadvantages  such  as  risk,  time  available  and  combat  power  ratios. 
Decision  support  templates  are  more  flexible  In  their  content  than  most 
of  the  other  IPB  templates  and  the  interactive  features  of  the  system 
are  necessary  to  support  this  ad  hoc  process.  The  system  graphics 
function  DRAW  (free  form  figures,  shading,  variation  of  color  intensity) 

Is  essential  to  enable  the  IPB  analyst  to  rapidly  augment  other  templates/ 
working  displays  In  building  the  decision  support  templates  and  to  make 
modifications  as  directedd  by  the  commander. 
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Figure  3. 1.3-8  depicts  the  process  by  which  a  decision  support 
template  is  prepared  and  presented  to  the  commander  for  his  consider¬ 
ation.  A  defensive  plan  has  been  used  as  the  example,  but  friendly 
offensive  operations  may  be  portrayed  on  the  IPB  decision  support 
template  also.  Not  shown  in  Figure  3. 1.3-8,  but  also  available  in 
the  IPB  system  are  more  detailed  1:50,000  scale  displays  of  terrain 
features  which  may  be  used  to  show  significant  areas  of  operation. 

Should  a  preliminary  decision  support  template  have  been  prepared 
during  the  G-3  build  phase  (see  Section  3. 1.2. 3. 8)  it  would  be  used  to 
initiate  the  process.  Otherwise,  the  initial  display  is  constructed 
by  merging  the  planned  routes  (for  the  appropriate  enemy  options),  the 
line  of  contact  and  military  boundaries  from  the  current  situation 
graphics  data  base  on  a  map  of  the  area.  The  analyst  uses  system 
graphics  features  such  as  changing  color  or  intensity  or  pattern  of 
the  planned  routes  to  highlight  the  option  which  the  enemy  is  thought 
to  be  executing. 

Using  one  of  the  maneuver  courses  of  action  as  represented  by  a 
maneuver  decision  alternative  template,  the  analyst  adds  to  the  graphics 
display: 

e  Line(s)  of  defense  and/or  phase  lines 

•  Time  available  (to  execute  this  course  of  action) 

•  Symbols  generally  depicting  key  elements  of  the  operation, 

i.e.,  attack  positions,  defended  areas,  landing  zones  or 
droo  zones. 

The  system  capability  required  to  facilitate  this  process  consists  of 
building  a  new  overlay  from  an  existing  display.  Once  the  "new  overlay" 
graphics  function  is  initiated,  the  analyst  indicates  on  the  CRT  those 
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3. 1.3-8.  Comnander's  Decision  Support  Function  (Sheet  1  of  2) 
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features  which  he  desires  to  use  in  the  new  display.  "Hooking"  a 
symbol /flag,  changing  Its  color  or  blinking  it,  for  example  might  serve 
as  the  way  that  symbol/flag  is  retained  on  the  new  display.  A  second 
way  the  analyst  could  create  the  new  display  is  by  deleting  unwanted 
elements  of  the  current  display. 

Once  this  "new  overlay"  is  on  the  graphics  CRT,  the  previously 
prepared  (partial)  decision  support  template  is  recalled  from  temporary 
storage  and  merged.  This  operation  completes  one  decision  support 
template.  Others,  as  necessary,  are  similarly  prepared. 

Since  decision  support  templates,  in  themselves,  are  not  intended 
to  present  accomplished  decisions  to  the  commander,  the  next  subfunction 
is  to  prepare  one  or  more  of  these  templates  to  the  commander  for  his 
consideration  and  comment.  As  indicated  in  Sheet  2  of  Figure  3. 1.3-8  this 
process  involves  displaying  a  decision  support  template  on  the  graphics 
CRT,  augmenting  it  as  necessary  with  maneuver  detail s--represented 
by  the  maneuver  decision  alternative  template  and  with  the  fire  support 
planning- -represented  by  the  fires  decision  alternative  template  and 
the  target  analysis  matrix.  The  essence  of  each  friendly  course  of 
action  Is  presented  to  the  corrmander  in  graphic  and  A/N  format.  The 
ensuing  discussion  between  the  commander,  G-3  and  G-2  may  require 
modification  of  one  or  more  decision  support  templates.  The  analyst 
will  make  online  changes  during  the  discussion.  The  result  would  be 
useful  graphic  and  alphanumeric  expressions  of  the  commander's 
decisions  regarding  operating  plans. 

Figure  3. 1.3-9  is  one  example  of  a  decision  support  template. 

The  primary  enemy  course  of  act1on--a  double  envelopment  attack  by  two 
second  echelon  divisions  Is  shown  in  blue,  an  alternative--a  penetration 
attack  Is  shown  in  red,  and  the  friendly  line  of  defense  is  shown  by 
dashed  white  lines.  Additional  symbols  were  not  used  in  this  example. 
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Figure  3.13-9  Fvample  of  CommandtA  Derision  Support  Template 


3.2  SYSTEM  SOFTWARE  FUNCTIONS 


The  system  attributes  required  to  support  IPB  applications  described 
in  previous  sections  provide  the  foundation  for  the  function  definitions 
in  this  section.  The  focus  is  on  the  application-independent  system 
software  for  IPB  as  part  of  an  ASAS. 

3.2.1  Operating/Control  System  Software  Functions 

The  operating/ control  system  software  functions  of  IPB  are  similar 
to  other  ASAS  applications.  They  include: 

•  Task/job  initiation  and  termination 

•  Task  and  subtask  management 

•  Device  support 

•  Data  management 

•  Software  development  facilities. 

Task/Job  Initiation  and  Termination 

This  function  allows  tasks  or  jobs  to  be  initiated  in  a  multi¬ 
tasking  or  multi  programing  environment.  Tasks  shall  be  initiated  as 
background  jobs  or  as  online/real  time  jobs.  Resources  such  as  main 
memory,  terminals,  peripheral  devices  and  data  sets  shall  be  allocated 
or  assigned  at  task  initiation  and  released  at  task  termination. 

Task/Subtask  Management 

This  function  allows  tasks  to  spawn  subtasks  and  tasks  and  subtasks 
to  •>*  executed  on  the  basis  of  relative  priority.  This  function  manages 
and  external  Interrupts  and  supervises  the  dynamic  utilization 
•  r\ tw»  resources. 


3-150 


Device  Support 

This  function  provides  physical  I/O  handling  for  the  devices 
required  for  IPB.  These  devices  are  direct  access  storage  devices 
(disks),  magnetic  tape,  alphanumeric  terminals,  colorgraphic  displays 
and  a  graphic  data  tablet.  I/O  support  for  the  colorgraphic  displays 
is  discussed  further  in  Section  3.2.4. 3. 

Data  Management 

This  function  provides  data  management  services  or  access  methods 
for  a  device  independent  Interface  between  application  programs  and  the 
physical  devices.  The  allocation  of  specific  devices  to  application 
programs  occurs  at  task  initiation.  The  data  management  services  shall 
provide  a  high  level  macro  language  for  application  programmers. 
Sequential,  indexed  sequential,  partitioned,  direct  and  telecommuni¬ 
cation  access  methods  are  required. 

Software  Development  Facilities 


This  function  provides  software  development  facilities  for  IPB 
application  programming.  The  facilities  required  are: 

•  Compilers  -  FORTRAN,  COBOL  (for  example) 

•  Assembler  -  Basic  assembly  language  with  macros 

t  Library  Support  -  Structured  progranml ng  support  library 

•  Utilities  -  data  transfer  and  data  manipulation. 
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3.2.2  Terminal  Processing  Software  Functions 


The  terminal  processing  software  functions  described  In  this 
section  can  be  part  of  the  operating/control  system  or  execute  as 
tasks  running  under  the  control  of  the  operating/control  system. 

The  terminal  processing  software  functions  include: 

•  Terminal/display  Interface 

•  Online  task  supervision  and  event  driven  cycling 

•  Display  formatting 

•  Terminal  to  terminal  communications 

•  Online  utilities. 

Terminal/Olsplay  Interface 

This  function  provides  the  software  Interface  for  the  alphanumeric 
terminals  and  the  colorgraphlc  displays.  This  Interface  shall  support 
multiple  terminals  interfaced  with  the  same  or  different  data  base 
management  and  graphic  application  programs.  The  interface  shall 
support  both  demand  and  queued  I/O.  Queued  I/O  shall  be  supported 
with  Input  error  corrections  and  output  paging  capabilities. 

Online  Task  Supervision  and  Event  Driven  Cycling 

This  function  involves  supervising  the  dynamic  execution  of  data 
base  management  and  graphic  application  programs  based  on  operator 
Interaction  with  the  IPB  terminals  and  displays.  It  includes  dynamic 
resource  management  and  subtask  control  based  on  terminal  or  event 
priority.  This  software  supports  event  driven  cycling  of  data  base 
management  and  graphic  application  programs.  This  means  that  an 
appllcatlor,  program  shall  be  able  to  Initiate  or  change  a  cycle  of 
program  executions  based  on  the  results  of  processing  a  particular 
Input. 
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Display  Formatting 


This  function  provides  the  user  oriented  terminal  interaction 
required  for  IPB  activities.  The  alphanumeric  terminal  operator  shall 
be  able  to  call  up  display  formats  for  data  entry,  query  preparation, 
report  selection  and  message  generation.  The  display  contents  shall 
consist  of  prestored  information,  data  from  the  data  base  management 
system  or  data  to  be  entered  by  the  terminal  operator. 

Terminal  to  Terminal  Communications 


This  function  can  be  ad  hoc  or  automatic,  that  is,  initiated  by  a 
terminal  operator  or  initiated  by  an  application  program.  The  terminals  ‘ 
involved  are  the  alphanumeric  terminals.  Two  modes  of  terminal  to 
terminal  communication  are  required.  These  are  alert  messages,  which 
are  immediately  displayed  on  the  bottom  line  of  the  display,  and  queued 
messages,  which  are  placed  on  a  message  queue  with  an  alert  message  to 
the  operator  to  inform  him  that  a  message  has  been  placed  in  the  queue. 


Online  Utilities 


These  functions  support  the  online  interactive  environment  of  the 
IPB  analyst.  The  followinq  capabilities  are  required: 

•  Online  creation,  modification,  display  and  deletion  of 
working  files 

•  Printing  of  display  contents,  data  sets  and  messages 

•  Terminal  to  computer  operator  messages 

•  Input  and  output  queue  management. 
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3.2.3  Data  Base  Management  Software  Functions 


The  data  base  management  software  shall  support  the  IPB  applications 
in  a  flexible  manner  to  enable  the  IPB  analysts  to: 

•  Enter  and  retrieve  all  required  data  from  the  data  base 

•  Automatically  process  inputs  and  outputs  in  a  flexible 
manner  to  permit  easy  direction,  tailoring,  and  high¬ 
lighting  of  important  information 

•  Readily  pursue  important  information  leads  on  an  ad  hoc 
basis 

•  Easily  communicate  results  to  other  analysts  and  interfacing 
systems . 

The  basic  data  base  management  software  shall  contain  capabilities 

for: 

•  Structure  and  structure  revision  of  a  broad  set  of  files.  This 
will  ensure  that  as  the  application  functions  evolve,  the  data 
base  can  flexibly  change  to  meet  the  new  requirements  in  a  time 
responsive  manner. 

t  Complete  background  and  online  file  maintenance  to  include 
initialization,  change  and  purge  of  data  contained  within  the 
various  structured  files. 

•  Online  query  processing  to  retrieve  and  output  data  to  using 
analysts  or  graphic  application  programs. 
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Figure  3.2-1  presents  an  overview  of  the  system  environment,  inputs, 
processes,  and  outputs  which  shall  be  incorporated  in  the  data  base 
management  software  function.  Basic  inputs  are  in  the  form  of: 

•  Local  terminal  network  inputs 

•  Graphic  processing  inputs 

•  Background  task  initiations. 

Basic  outputs  are: 

•  Local  terminal  network  outputs 

•  Outputs  to  graphics  processing  (qualified  record  data  for 
graphical  display). 

In  addition  to  these  specific  Inputs  and  outputs,  the  data  base  is 
an  input/output  for  many  of  the  IPB  processes. 

3.2.3. 1  File  Structuring/Revision 

The  file  structuring/ revision  subfunction  permits  the  creation  and 
reorganization  of  file  structures  which  are  supportive  of  the  IPB 
functions.  This  subfunction  permits  non-progranmers  to  specify  data 
structures  required  to  support  the  applications  and  evolutions  of  these 
applications.  This  is  accomplished  by  a  simple  language  convenient  to 
the  user.  The  file  structuring  subfunction,  together  with  the  operating/ 
control  system,  shall  permit  a  high  degree  of  independence  from  the 
physical  data  storage. 

File  Concept 

The  system  shall  permit  management  of  a  broad  spectrum  of  data  in 
an  organizational  manner  equivalent  to  the  hierarchical  organization 
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Figure  3.2-1.  Data  Base  Management  Subsystem  Overview 


shown  on  Figure  3.2-2.  The  description  below  is  representative  of  the 
flexibility  of  the  file  structure  necessary  to  support  the  IPB 
application. 


The  terms  used  in  this  subparagraph  are  defined  as  follows: 


•  Data  Base  A  collection  of  data,  supporting  the  general 

mission  or  applications  of  the  system.  It  is 
typically  composed  of  many  different  logical 
data  sets  (commonly  called  files). 

•  Data  File  A  logical  set  of  data  elements,  grouped  into 

associated  arrays  called  records. 


•  Data  File 
Records 


That  collection  of  data  elements  identifiable 
by  a  unique  data  value  or  key. 


•  Field 


A  single  data  element. 


•  Secondary/ 
Keyword 
Indexing 


The  capability  to  index,  or  access,  the  contents 
of  a  data  file  by  a  means  other  than  the  record 
identifier.  The  index  data  set  is  a  logical 
data  set  of  all  index  values  and  the  data 
records  associated  with  each. 


It  shall  be  possible  to  carry  both  repetitive  and  nonrepetiti ve 
information  in  a  file  record  in  fixed  and  periodic  information  sets. 
Collections  of  field  strings  having  the  same  format  are  called  sets. 
Therefore,  the  string  of  fields  containing  nonrepetitive  data  in  a 
file  record  is  called  the  fixed  set.  Periodic  fields,  grouped  and 
recurring  as  strings,  are  called  periodic  sets. 
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Figure  3.2-2.  Data  Base  Organization  for  N  File  Data  Base 


The  record  structure  within  a  file  shall  contain  a  fixed  set,  with 
a  minimum  of  one  level  of  subordination  (the  periodic  set  or  sets). 

The  format  of  a  fixed  set  shall  be  constant  throughout  one  file.  More 
than  one  periodic  set  may  be  defined  in  the  file  structure,  but  as  in 
the  case  of  the  fixed  set,  the  format  shall  be  constant  throughout  the 
file  on  a  set-by-set  basis.  In  other  words,  the  format  of  the  first 

periodic  set  in  each  record  is  the  same,  and  the  format  of  the  second 

periodic  set  in  each  record  is  the  same  and  so  on.  The  formats  of 

periodic  set  1  and  periodic  set  n,  however,  need  not  be  the  same. 

The  user  shall  be  able  to: 

•  Include  a  variable  field  within  the  definition  of  each  of 
the  fixed  or  periodic  sets.  (This  field  can  contain  variable 
length  character  strings  and  shall  be  included  in  physical 
storage  only  whan  there  is  actual  data  in  the  field.) 

•  Structure  several  variable  sets.  (Each  variable  set  contains 
a  variable  length  character  string  and  shall  exist  only  when 
data  is  present.) 

•  Retrieve  records  based  on  the  content  of  variable  data  fields 
by  either  executing  a  scan  of  the  field  for  the  qualifying 
value(s)  or  by  employing  a  keyword  indexing  capability. 

Secondary  and  keyword  indexing  capabilities  shall  be  available  to 
enable  a  user  to  have  more  flexible  control  over  his  data.  Secondary 
indexing  shall  permit  the  specification  of  fixed-length  fields  as  indexes 
and  retrieval  of  records  based  on  the  contents  of  those  fields.  Keyword 
indexing  shall  permit  the  specification  of  variable  fields,  variable 
sets,  and  fixed-length  fields  as  Indexes;  selecting  values  from  the 
field  as  keywords;  and  retrieving  records  based  on  the  presence  of  the 
keywords  within  the  queried  fields. 
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File  Structuring 


File  records  (the  collection  of  the  fixed,  periodic,  and  variable 
sets  which  are  uniquely  identified  by  a  record  identifier  or  key)  shall 
not  be  unnecessarily  restricted  as  to  size.  The  system  shall  perform 
dynamically,  giving  the  user  a  high  degree  of  flexibility. 

During  the  file  definition  process,  the  user  shall  be  able  to 
specify  in  advance  certain  automatic  functions  such  as  conversion  of 
retrieval  literals  to  coded  file  values,  output  data  conversions,  or 
editing.  If  file  indexing  is  desired,  the  user  shall  be  able  to 
indicate  which  field  or  fields  will  provide  the  index  values.  The 
file  structuring  subfunction  shall  provide  mechanisms  for  this  purpose 
and  record  these  characteristics.  Record  control  or  key  fields  may  be 
defined  as  a  single  field  or  a  string  of  multiple  fields.  Periodic 
subsets  may  also  have  data  fields  assigned  for  sequencing  and  control 
within  the  record.  If  the  user  does  not  desire  to  provide  these  subset 
control  elements,  the  system  shall  create  sequence  numbers  for  the 
control  function  and  maintain  them  as  a  normal  part  of  the  file  main¬ 
tenance  subfunction. 

File  Revision 


The  file  structuring/revision  subfunction  shall  also  provide  the 
capability  to  revise  the  format  in  which  data  is  stored  in  a  data  file. 

It  shall  be  possible,  under  the  file  revision  subfunction,  to: 

•  Add,  delete  and  relocate  fields  as  well  as  change  their  storage 
mode,  size  and  name 

e  Delete,  relocate  or  add  periodic  sets  (on  adding  a  periodic 
set  no  data  will  be  Included  as  a  result  of  the  file  revision 
subfunction) 
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•  Split  any  set  in  the  old  file  into  several  sets  in  the  new 
fi  le. 

3. 2. 3. 2  File  Generation  and  Maintenance 

The  file  maintenance  subfunction  shall  provide  the  user  with  a 
capability  for  generating  and  maintaining  data  files.  The  user  shall 
be  able  to  add,  delete,  or  change  file  records,  periodic  sets  or  subsets, 
and  variable  sets.  Also,  the  user  may  modify  or  change  file  fields  and 
may  change  (increase  or  decrease)  the  volume  of  data  associated  with  any 
file  record.  If  indexing  is  specified  for  the  file,  the  index  data  set 
shall  also  be  maintained.  This  index  data  set  maintenance  shall  be 
automatic  and  transparent  to  the  user. 

All  processing  shall  be  controlled  by  logic  statements  provided  by 
the  user.  These  statements  may  be  in  either  a  macro-like  programmer- 
oriented  language  or  a  high-level  procedural  English-like  language  which 
shall  be  easy  to  learn  and  simple  to  use.  The  languages  shall  include 
instructions  that  permit  automatic  table  translation  and  validation  or 
automatic  linkage  to  user  provided,  special  purpose,  subroutines. 

Data  Initialization 


A  method  shall  be  established  to  initialize  the  data  required  for 
IPB  applications.  After  initialization,  the  appropriate  new  or  changed 
information  shall  be  made  available  in  real  time.  Some  of  the  IPB  data 
shall  be  initialized  at  their  default  value  with  permitted  review  and 
change  activity  initiated  by  manual  intervention.  Other  IPB  data  is 
not  initialized  but  is  input  to  the  system  in  real  time. 
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Recovery 


A  method  shall  be  established  to  permit  the  IPB  system  to  recover 
from  certain  short  period  outages  employing  system  log/ recovery  process¬ 
ing  techniques.  Catastrophic  short  period  outages,  as  well  as  long 
duration  outages  will  not  be  recoverable  but  will  require  reinitiali¬ 
zation  of  the  system. 

Purge 

The  system  shall  permit  initiation  of  modifiable  prestored  purge 
commands  which  will  delete  data  base  information  which  is  no  longer 
needed.  The  modifiable  prestored  purge  commands  shall  be  capable  of 
logical  qualification  based  upon  combinatorial  logic  involving  virtu¬ 
ally  any  of  the  stored  data  base  fields.  It  shall  be  possible  for 
example  to  purge  based  upon  logical  combinations  of  time,  area,  subject, 
and  report  source.  The  purge  process  shall  not  require  cessation  of 
the  online  functions.  Data  integrity  shall  be  preserved  during  the 
purge  process. 

Online  Update 

The  terminal  processing  system  shall  permit  online  file  maintenance 
when  initiated  via  terminal  request  or  when  initiated  by  another  IPB 
application  program. 

The  online  update  component  shall  permit  translation  of  externally 
used  data  values  to  coded  data  base  values  as  required.  The  translation 
function  shall  consist  of  an  expandable  argument/function  dictionary. 
Upon  input,  the  argument  is  the  user  or  external  system  input  name  for 
the  data  element  and  the  function  substituted  for  this  in  the  data  base 
is  the  internally  coded  data  element  form.  Often  multiple  user  names 
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look  up  the  same  coded  form.  A  separate  table  can  be  used  by  the  output 
process  modules  to  take  the  internally  coded  form  as  the  argument  and 
look  up  the  user  or  esternal  system  output  form.  User  or  external  system 
input  values  do  not  have  to  equal  output  values. 

Online  update  shall  be  accomplished  by  means  of  executing  a  file 
maintenance  logic  statement  against  an  update  transaction  entered  either 
by  an  operator  or  another  I PB  application  program.  The  input  transaction 
is  validated  by  the  logic  statement  during  execution,  if  errors  are 
detected,  inmediate  notification  will  be  given  to  the  terminal  operator. 

Online  update  shall  perform  a  process  called  filtering  during  the 
execution  of  the  file  maintenance  logic  statements.  The  filtering 
function  determines  if  a  predetermined  significant  event  has  occurred 
as  represented  by  the  incoming  transaction  and  its  relationship  to  the 
data  base.  The  result  of  the  filtering  function  can  be  initiation  of 
additional  or  different  I PB  application  programs.  An  example  would  be 
a  transaction  which  causes  a  prestored  query  to  be  executed  and  a 
graphic  display  to  be  updated. 

3. 2. 3. 3  Query  Processor 

The  query  processor  shall  give  the  user  (either  terminal  user  or 
other  system  processing  module)  an  online  data  retrieval  language  and 
display  language  for  outputting  data.  Such  online  processing  shall 
include  the  capability  to  execute  modifiable  prestored  retrieval  commands. 

File  records  shall  be  qualified  for  output  by  simple  or  compound 
conditions  being  met.  Legal  subjects  of  the  conditional  expression 
shall  be  any  field  names.  The  query  processor  shall  be  able  to  limit 
the  numbe  •  of  data  records  that  must  be  examined  in  detail  through  the 
use  of  file  indexing  of  potential  candidate  records  when  the  secondary 
index  function  is  utilized. 
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Relational  operators  shall  be  provided  for  equal  to,  greater  than, 
greater  than  or  equal,  less  than,  less  than  or  equal,  between,  and  not- 
equal  conditions.  All  relational  operators  may  be  preceded  by  the 
negative  operator  'not'.  Geographic  search  operators  shall  be  provided 
for  determining  if  a  point  is  contained  within  an  area,  a  line  inter¬ 
sects  or  is  contained  within  an  area,  a  line  intersects  a  line,  or  an 
area  is  contained  within  or  overlays  an  area;  or  for  testing  if  a 
geographic  point  lies  within  a  circle  defined  by  a  literal  consisting 
of  a  point  and  radius. 

Any  geographic  area,  line,  or  point  shall  also  be  usable  as  the 
selection  criterion  for  producing  an  output  report. 

The  query  processor  shall  also  provide  a  facility  which  allows  the 
user  to  write  his  own  subroutine  to  assist  in  record  qualification  and 
data  presentation.  The  subroutine  shall  be  written  as  a  conditional 
clause  and  may  have  in  the  parameter  list  literals,  field  names,  and 
work  areas. 

Compound  conditional  expressions  shall  be  permitted  by  the  use  of 
the  logical  connectors  AND  or  OR.  An  unlimited  number  and  level  of 
parentheses  shall  be  allowed,  and  where  nested  parentheses  are  used, 
the  expression  contained  in  the  most  deeply  nested  parentheses  is 
evaluated  first.  Successively  higher  levels  are  evaluated  until  the 
truth  factor  for  the  entire  statement  has  been  determined.  The  user 
shall  be  able  to  modify  the  logic  of  a  query  compound  expression 
against  an  item  of  a  repeating  group  with  the  ANY  modifier.  This 
modifier  shall  change  the  conditional  logic  so  that  successive  terms 
against  the  same  periodic  set  are  not  evaluated  within  one  subset  at 
a  time,  thus  permitting  a  record  to  be  qualified  if  an  item  of  a 
repeating  group  has  different  values. 
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The  query  processor  shall  provide  for  subroutine  conversion  to 
qualify  encoded  values.  Subroutine  conversion  may  be  specified  in  the 
retrieval  statement  or  performed  automatically  for  items  designated 
for  subroutine  conversion  at  file  definition  time.  This  automatic 
subroutine  conversion  may  be  suppressed  or  overridden  with  another 
subroutine  at  retrieval  time. 

The  query  processor  shall  provide  flexible  display  output  operators. 
As  an  example,  the  user  shall  be  permitted  the  capability  to  list  the 
contents  of  any  field  in  the  file  in  such  a  manner  as  to  produce  a 
columnar  report.  The  system  shall  generate  as  many  columns  and  output 
lines  as  needed  to  list  all  of  the  specified  fields;  however,  if  all  the 
fields  will  not  fit  on  a  single  line  of  output,  the  fields  will  be  sorted 
by  set  number  and  displayed  accordingly.  When  more  than  one  output  line 
is  generated  for  a  record,  all  lines,  except  the  first,  shall  be  easily 
identified  as  a  continuation  of  a  record.  Column  headings  shall  be 
generated  automatically  from  the  output  labels  associated  with  the  speci¬ 
fied  fields  when  the  file  was  defined.  If  no  output  label  was  assigned 
to  the  field,  the  field  name  shall  be  displayed. 

The  query  processor  shall  provide  for  computational/logical 
tailoring  of  output  results  to  include  sumnation  and  counting  of 
selected  data  fields  prior  to  output. 

3.2.4  Graphics  Processing  Software  Functions 

Software  functions  for  supporting  IPB  graphics  processing  are 
described  in  the  following  paragraphs.  The  intent  Is  to  describe 
representative  functions  but  not  Indicate  that  any  one  or  group  of 
functions  be  performed  In  a  specific  way  by  a  specific  programing 
routine.  Any  software  design  approach  which  allows  equally  convenient 
and  effective  performance  of  these  functions  shall  satisfy  these 
requirements.  The  functions  are  described  in  two  categories: 
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•  Graphic  Application  -  Graphic  application  functions  are 

operator  Initiated  and  designed  expressly  for  military 
applications  such  as  IPB. 

•  Graphic  Support  -  Graphic  support  functions  are  general 

purpose  providing  system  support  of  image  management 
and  image  generation  which  are  basic  to  the  graphic 
display  capabilities. 

An  overview  functional  diagram  of  these  elements  is  presented  in 
Figure  3.2-3. 

3.2.4. 1  Interactive  Controls 

Interactive  devices  of  the  types  enumerated  below  shall  provide 
for  user  communication  with  displays.  Graphics  software  functions  shall 
provide  the  appropriate  responses  when  activated  by  these  or  equivalent 
devices. 

Function  Keyboard 

Function  keys  shall  be  used  to  start  and  terminate  functions  and 
routines.  Each  function  key  shall  be  reprogrammable  by  a  computer 
programmer  with  sufficient  skill  and  experience  to  understand  the  basic 
software  system.  Each  function  key  shall  indicate  status  of  the  function 
it  controls  by  lighting,  changing  color,  or  by  some  other  equally  visible 
technique. 

Software  for  translating  function  key  codes  shall  be  designed  to 
support  at  least  45  separate  function  keys  and  at  least  300  individual 
function  codes  assuming  that  a  hierarchical  control  tree  structure  is 
employed. 


OPEMTING/CONTROL 


Processing  Subsystem  Overview 


Where  complex  function  key  sequences  are  employed,  preempting 
messages  shall  be  provided  to  the  operator  to  aid  in  performing  the 
sequence. 

Trackball /Cursor 

A  trackball /cursor  combination  (or  equivalent  control)  shall  be 
used  in  conjunction  with  the  function  keys  and  other  interactive  con¬ 
trols  to  move  symbols,  to  draw  lines,  and  to  perform  other  functions 
that  require  positioning  of  a  point  or  symbol  on  the  display  screen. 

The  cursor,  in  a  crosshair  shape,  shall  be  provided  to  allow  the 
operator  to  sense  location  and  movement  on  the  screen  in  response  to 
commands  from  the  trackball.  The  system  shall  be  designed  so  that 
upon  request  made  by  function  key,  the  Military  Grid  Reference  (MGR) 
coordinates  of  the  cursor  location  are  displayed  either  under  the 
cursor  or  at  some  previously  designated  standard  position  on  the 
screen. 

Alphanumeric  Character  Set  Controls 

Suitable  key  functions  shall  be  provided  for  displaying  the  full 
set  of  64  ASCII  characters.  Supporting  software  shall  be  capable  of 
Interfacing  the  function  keyboard  with  a  standard  typewriter  keyboard 
configuration  or  interfacing  with  the  equivalent  functions  Implemented 
as  a  part  of  the  function  key  hierarchical  control  tree  structure. 

3. 2.4. 2  Graphic  Applications  Software 

The  software  functions  making  up  the  graphic  applications  software 
are  described  below  In  the  following  categories: 

•  Control  program 

•  Data  base  interface  subroutines 
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•  Function  key  translator 

•  Operator  action  subroutines. 

3. 2. 4. 2.1  Control  Program 

The  control  program  function  shall  handle  external  interrupt  comnu- 
nications,  the  engagement/ disengagement  of  the  several  application  routines 
and  the  graphics  processing  Initialization/table  load  functions.  It 
shall  operate  in  an  asynchronous  mode  under  the  Terminal  Processing 
System  and  Operating/Control  System.  Interrupts  will  be  queued  and 
handled  in  accordance  with  predefined  priority  rules.  This  program 
shall  gain  control  of  operations  whenever  all  graphic  application 
program  outstanding  requests  are  completed.  At  such  time  the  control 
function  enters  the  wait  state  until  the  next  request  for  service  is 
posted. 

During  initialization  the  system  responds  directly  to  operator 
communi cati on  via  the  function  keyboard,  trackball/cursor  or  alphanumeric 
keyboard.  The  objective  is  to  assemble  those  files,  tables  and  programs 
which  satisfy  the  machine  configuration,  the  connected  display  terminals, 
and  the  graphics  performance  requirements. 

3.2.4. 2. 2  Data  Base  Interface  Subroutines 

The  data  base  Interface  subroutines  shall  handle  exchange  of  infor¬ 
mation  between  the  graphics  processing  software  functions  and  the  data 
base  management  subsystem.  These  interface  subroutines  shall  be  designed 
to  accomplish  the  transfer  of  formatted  requests  (generated  from  the 
Interpretation  of  function  key  codes)  through  the  terminal  processing 
system  to  the  data  base  subsystem  and  to  receive  information  from  the 
data  base  subsystem,  causing  this  data  to  be  linked  back  to  the  request¬ 
ing  terminal  by  the  graphics  processor  subsystem. 
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Interface  subroutines  shall  provide  for: 


•  Query  of  the  data  base  for  specific  data  records. 

•  Search  of  the  data  base  for  logical  combinations  of  data 
elements. 

•  Transfer  to  the  data  base  management  subsystem  of  MGR 
coordinates  of  a  cursor  identified  symbol  or  other  graphic 
feature  with  a  link  to  the  associated  query/search. 

•  Transfer  to  the  data  base  management  subsystem  of  trackball 
generated  polygon  shape  with  a  link  to  the  associated 
query/search. 

3. 2. 4.2. 3  Function  Key  Translator 

The  Function  Key  Translator  subroutines  shall  be  designed  to 
service  all  manual  Inputs  received  through  the  graphics  display 
function  keys.  The  subroutines  shall  interpret  the  key  codes  and 
shall  Invoke  the  appropriate  operator  action  subroutines  thereby 
enabling  and  causing  execution  of  Instructions  for  the  display, 
manipulation,  storage  and  recall  of  graphics  data  as  selected  by 
the  display  operator's  actions. 

3.2. 4. 2. 4  Operator  Action  Subroutines 

The  functions  enumerated  In  this  section  are  those  that  accomplish 
processing  In  response  to  operator  Instructions  and  data  entered  through 
the  function  keys  and  trackball/cursor.  They  are  the  routines  that  allow 
the  user  to  build  and  manipulate  symbols,  to  free  draw  graphics,  and  to 
call  and  remove  scene  data  and  overlays. 
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These  are  described  below  in  terms  of  the  function  capabilities 
inherent  in  the  keyboard  and  trackball /cursor  controls. 


SYMBOL  CONTROLS 

Build  Symbol 

The  build  symbol  function  will  invoke  the  appropriate  subroutine  to 
create  a  new  symbol  in  the  graphic  display  area  and  simultaneously  on 
the  display  screen. 

If  symbol  type  selected  is  a  standard  military  flag  (rectangle)  the 
software  function  plus  operator  interactions  shall  compose  this  from 
multiple  elements  in  the  standard  symbol  library.  A  different  software 
function  shall  be  invoked  to  compose  special  military  graphic  symbols 
such  as  a  minefield,  missile  site,  artillery  location,  etc.  Still  a 
different  software  function  shall  be  invoked  to  compose  vector  symbols 
which  are  formed  by  a  series  of  line  vectors  in  a  specified  arrangement 
and  size. 

Rotate  Symbol 

Another  software  function  shall  be  invoked  to  permit  rotation  of 
the  vector  symbols  during  build  or  as  a  separate  operation.  Placement 
on  the  screen  shall  be  accomplished  either  by  fixing  the  symbol  origin 
via  trackball/cursor  control  or  via  entry  of  MGR  data  through  the 
function  keys.  Software  function  design  shall  allow  accuracy  of  place¬ 
ment  to  within  +150  meters  with  respect  to  map  background  at  a  scale  of 
1:50,000.  The  accuracy  of  orienting  vector  symbols  shall  allow  rotation 
to  within  +5*  of  the  cursor-identified  orientation. 
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Move  Symbol 


When  this  function  is  actuated,  a  subroutine  will  be  enabled  to 
move  the  cursor- identified  symbol  origin  to  a  new  screen  location.  The 
symbol  and  all  amplifying  data  shall  move  as  a  group  to  a  new  screen 
location  as  identified  by  the  cursor  position.  This  subroutine  will 
also  allow  repositioning  of  the  symbol  to  a  new  location  in  response 
to  coordinates  entered  through  the  function  keyboard  or  the  alphanumeric 
keyboard. 

Declutter 


When  this  function  is  actuated,  a  subroutine  will  be  enabled  to 
move  the  symbol  flag  (keeping  the  symbol  origin  fixed)  to  a  new  screen 
location  to  allow  decl uttering.  The  flag  and  all  amplifying  data  shall 
move  as  a  group  to  a  new  screen  location  as  identified  by  the  cursor 
position.  This  subroutine  shall  allow  bending  of  the  staff  between 
flag  and  origin,  placement  of  the  inflection  point  being  fixed  by  the 
cursor  location  marked  by  the  operator. 

Label 


When  this  function  is  actuated  a  subroutine  will  be  enabled  to 
allow  annotation  (applied  for  the  first  time  or  modified)  of  a  symbol. 

Suppress 

When  this  function  is  actuated  a  subroutine  will  be  enabled  to 
allow  the  temporary  removal  of  a  symbol,  group  of  symbols,  or  overlay 
from  the  display  screen.  The  element  so  identified  is  suppressed  but 
not  removed  from  the  graphic  data  output  area  of  memory.  An  element 
suppressed  in  this  manner  will  be  redisplayed  automatically  the  next 
time  the  stored  frame  is  called  up  for  display. 
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Delete 


When  this  function  is  actuated,  a  subroutine  will  be  enabled  to 
cause  removal  of  a  cursor  identified  symbol,  group  of  symbols,  or  over¬ 
lay  from  the  screen  and  from  the  graphic  data  output  area. 

Cancel 


When  this  function  Is  actuated,  any  processing  which  has  been 
initiated  will  be  terminated. 

Group 

This  function  shall  provide  a  capability  to  collect  a  number  of 
unit  symbols  identified  by  cursor  action  for  aggregation  into  one 
element.  Thus  function  will  cause  an  Internal  table  to  be  written  to 
keep  track  of  the  unit  names  and  MGR  coordinates  associated  with  the 
element.  The  function  will  also  provide  the  capability  to  return  for 
display  the  data  stored  for  each  unit  in  the  element. 

Blink 


The  system  shall  be  designed  so  that  any  character,  symbol,  or 
group  of  symbols  and/or  characters  may  be  caused  to  blink  on  and  off 
to  call  the  blinking  symbols  to  the  attention  of  the  console  operator. 
The  system  shall  be  designed  so  as  to  start  and  stop  blinking  either 
by  software  command  as  a  part  of  the  software  routine  or  as  a  result 
of  depressing  a  function  key  and  then  hooking  a  symbol  with  the  cursor 
or  other  control  device. 
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FREE  DRAW  GRAPHIC  CONTROLS 


Select  Dash  Line  Type 

When  this  function  is  actuated  a  subroutine  shall  use  a  dashed 
line  for  lines  being  drawn. 

Draw  Line  Series 


When  this  function  is  actuated,  a  subroutine  shall  enable  the 
cursor  for  placement  of  successive  point  locations  which  the  system 
will  connect  with  straight  line  segments.  A  means  will  be  provided 
to  allow  termination  of  one  line  series  and  the  commencement  of  a 
new  line  series  in  either  the  same  or  different  line  type. 

Label  Unit  Boundaries 


When  this  function  Is  actuated,  a  subroutine  shall  enable  the 
cursor  and  keyboard  for  entry  of  an  echelon  symbol  and  alphameric 
data  identifying  the  military  organization  numerals  on  either  side 
of  the  echelon  symbol. 

SCENE  CONTROLS 


Select  Color 


When  this  function  is  actuated  the  subroutine  shall  Interpret  the 
color  selected  to  the  system  and  the  shading  pattern  for  that  color. 


Change  Symbol  Size 


When  this  function  is  actuated  a  subroutine  will  be  invoked 
causing  all  standard  military  symbols  on  the  display  (except  alphameric 
labels)  to  change  size. 

Scale 


When  this  function  is  actuated,  a  subroutine  will  be  invoked 
causing  the  cursor  identified  location  to  become  a  new  center  point 
and  causing  the  screen  picture  to  be  appropriately  repainted  to  the 
operator-specified  scale.  The  function  will  include  the  capability 
to  decrease  scale,  i.e.,  scale  by  a  fraction.  This  subroutine  shall 
handle  the  functions  required  to  perform  off-centering,  expansion, 
contraction  and  scissoring  of  screen  images.  Off-centering  shall 
allow  selection  by  cursor  of  a  new  geographic  center  for  an  area  to 
be  enlarged.  Expansion  shall  provide  the  computations  necessary  to 
rescale  all  symbol  positions  and  line  graphics  which  still  appear  in 
the  enlarged  image  area.  Scissoring  shall  provide  for  cutting  off  or 
stopping  graphics  data  where  it  runs  off  the  edge  of  the  display  screen. 
Provision  shall  be  made  for  rescaling  all  symbol  positions  back  to 
their  basic  position  from  expanded  positions.  This  subroutine  shall 
restore  to  the  display  screen  any  symbol  and  line  vector  data  that 
was  cut  off  when  the  base  scene  was  expanded. 

Save  Scene  (Temporary) 

Save  Scene  (Permanent 

This  function  shall  provide  for  labeling  and  temporary  or  perman¬ 
ent  storage  of  scenes. 
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This  function  shall  provide  for  calling  from  the  data  base  of  a 
previously  stored  scene  and  causing  the  display  of  this  data  on  the 
graphics  screen.  Call  up  shall  be  by  scene  label. 


Advance  Scene 


This  function  when  actuated  shall  cause  advance  of  the  display 
picture  from  the  scene  on  the  screen  to  the  next  scene  in  a  pre-defined 
sequence. 


Recycle 


This  function  when  actuated  shall  cause  the  screen  to  be  cleared 
of  all  image  information  and  cause  all  graphic  data  output  areas  and 
buffers  in  the  graphics  processor  to  be  reset. 


Call  Scene 

When  this  function  is  actuated,  the  scene  selected  will  be  dis¬ 
played  on  the  screen,  superimposed  on  any  scenes  already  present. 


>ress  Scene 


When  this  function  is  actuated,  the  scene  selected  will  be  sup 
pressed  from  the  screen  leaving  on  the  screen  any  scenes  previously 
present. 
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3.2.4. 3  Graphics  Support  Software 

IPB  graphics  processing  shall  incorporate  the  following  basic 
software  support  packages: 

§  Common  support  software  routines  that  allow  the  applica¬ 
tion  progranmer  to  work  with  the  graphics  processor  without 
requiring  him  to  have  intimate  knowledge  of  the  display 
hardware  or  the  data  formats  required  by  the  hardware. 

•  Image  management  routines  that  support  the  sequencing  and 
management  of  scenes  on  the  graphic  displays. 

•  Image  generation  routines  that  Interface  the  display  con¬ 
troller,  the  host  computer  and  the  data  produced  by  the 
image  management  routines. 

The  capabilities  to  be  provided  in  these  support  packages  are 
described  below.  The  intent  in  these  paragraphs  is  to  describe  standard 
routines  that  in  large  measure  are  common  to  many  commercially  available 
graphics  display  software  packages.  Any  set  providing  equivalent 
function  would  be  satisfactory. 

Common  Support  Software 

The  common  support  software  shall  utilize  a  library  of  subroutines 
to  execute  the  functions  of  operator  action  subroutines  and  Image 
management.  The  primary  objective  of  these  subroutines  shall  be  to 
facilitate  the  design  of  application  programs  which  need  not  repeti¬ 
tively  incorporate  the  code  for  formatting  and  managing  display 
elements.  All  the  subroutines  shall  have  standard  linkages  and  shall 
be  callable  either  from  assembly  language  or  compiler  language  programs 
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with  standard  call  statements.  The  routines  shall  be  table  oriented 
and  by  collecting  together  common  parameters,  shall  simplify  the 
communication  between  routines  and  reduce  the  amount  of  memory  required 
for  parameters. 

The  design  shall  be  such  that  the  storage  areas  for  these  tables 
shall  be  established  by  controls  carried  in  the  application  oriented 
programs;  routines  shall  be  available  for  initializing  these  tables. 

Image  Management 

Image  management  routines  shall  be  designed  to  serve  three  purposes. 
First,  they  shall  be  used  to  set  up  tables  which  serve  as  communication 
links  between  the  operator  action  subroutine  and  the  image  generation 
routines.  Second,  they  shall  be  used  to  generate  scenes  and  subscenes 
by  setting  up  an  index  to  the  area  in  which  graphic  data  is  stored  and 
provide  such  functions  as  name  maintenance  and  level  search.  Third,  the 
image  management  routines  shall  provide  the  user  with  the  ability  to 
modify  and  delete  scenes  that  have  previously  been  generated. 

The  subroutines  that  shall  comprise  the  basic  image  management 
support  capability  shall  include  functions  of  the  types  itemized  below: 

•  Initialize  control  blocks 

t  Begin  scene;  assign  scene  name  in  scene  correlation 
control  block 

•  End  scene 

•  Suppress  scene  from  screen 

•  Restore  scene  to  screen 

•  Compress  data  in  the  graphics  data  output  area  and 
scene  correlation  control  block 
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•  Add  scene 

t  Replace  scene 

•  Reallocate  space  for  either  the  graphics  data  output 

area  or  scene  correlation  control  block 

•  Change  scene  name 

•  Locate  scene  name  in  control  block  hierarchy. 

Image  Generation 

The  image  generation  subroutines  shall  be  used  to  create  appro¬ 
priate  control  words  to  be  used  in  requests  for  the  display  of  individual 
characters,  lines  of  characters,  individual  vectors,  and  connecting 
vectors.  It  shall  be  the  function  of  the  image  generation  subroutines 
to  take  data  supplied  by  the  user  and  interpreted  in  the  graphic 
application  programs  and  place  it  in  a  format  that  will  be  accepted 
by  the  graphic  display  controller. 

Tables  generated  by  the  graphic  application  and  image  management 
routines  serve  to  pass  parameters  to  the  image  generation  routines. 

The  routines  shall  search  these  tables  for  indication  as  to  what  is 
to  be  done  with  the  data  and  for  addresses  of  other  tables  necessary 
in  subsequent  processing. 

The  subroutines  that  shall  comprise  the  basic  image  generation 
support  capability  shall  Include  functions  of  the  types  Itemized 
below: 

•  Initialize  screen  parameter  table.  Define  portion  of  the 
graphic  display  area  to  be  used  if  an  expansion  or  contrac¬ 
tion  of  the  screen  image  is  called  for. 
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•  Compute  and  store  scissoring  parameters  to  control  the 
rescaling  of  symbol  screen  positions  for  an  expansion  or 
contraction  of  the  screen  image. 

•  Store  orders  (instructions)  for  display  of  individual 
characters. 

•  Store  order  for  display  of  a  string  of  characters. 

$  Generate  vectors  for  pairs  of  coordinates.  Control  order 
in  which  segments  are  connected 

•  Initialize  a  write  command  table  containing  a  channel  command 
word  for  each  element  in  the  graphic  data  output  area. 

•  Transfer  graphic  Information  In  the  graphic  data  output  area 
to  the  display  terminal  to  replace  previous  contents  of  the 
display  refresh  buffer. 

•  Transfer  partial  graphic  information  in  the  graphic  data 
output  area  to  the  display  to  be  added  to  the  contents  of 
the  refresh  buffer. 

e  Transfer  graphic  Information  in  the  graphic  data  output  area 
to  the  display  to  be  deleted  from  the  refresh  buffer  associ¬ 
ated  with  a  particular  display. 
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3.3  SYSTEM  PERFORMANCE/CAPACITY  REQUIREMENTS 


The  following  response  times,  processing  times,  accuracies,  resolu¬ 
tions,  and  data  capacities  are  the  nominal  requirements  for  effective 
implementation  of  the  IPB  software  outlined  in  Section  3.1. 


3.3.1  Response  Time  Requirements  at  Terminals 


Response  times  acceptable  to  the  IPB  operator/analyst  are  specified 
for  various  activities  at  the  terminals.  Response  times,  unless  mentioned 
otherwise,  are  measured  from  time  of  final  manual  action  by  the  analyst 
to  initiate  the  response  to  the  time  for  the  result  requested  to  appear 
on  the  display  screen.  Emphasis  is  on  those  IPB  activities  that  require 
the  most  time  to  complete  and  are  generic  to  operator-initiated  actions, 
namely: 


1.  System  response  to  actions  calling  -  Less  than  2  seconds 
for  display  of  directly  addressable 
graphics,  requiring  no  search  of 
the  data  base. 

Examples : 

a.  Display  of  query  format 

b.  Display  of  doctrinal  template 


2.  System  response  to  graphic  function  -  Less  than  2  seconds 
selection  calling  for  modification 
to  graphic  display  by  the  addition, 
relocation,  or  removal  of  graphic 
symbols  or  vectors. 
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Examples: 

a.  Display  of  graphic  symbol  at 
cursor  designated  position 

b.  Deletion  of  cursor  Identified 
symbol 

c.  Display  of  vector  at  the  graphic 
terminal  entered  at  the  Data 
Tablet 

System  response  to  graphic  function  -  Less  than  4  seconds 

selection  calling  for  extensive 

modification  of  the  displayed 

graphics,  requiring  search  through 

the  data  base/graphic  library,  but 

requiring  no  special  algorithm 

processing. 

Examples: 

a.  Display  of  a  different  map 
scale  of  the  same  general  area 

b.  Display  of  response  to  query 
of  disk-based  data  base 

System  response  to  graphic  function  -  Less  than  8  seconds 

selection  calling  for  extensive 

modification  of  the  displayed 

graphics,  requiring  special  algorithm 

processing  but  not  extensive  search 

through  the  data  base/graohic 

library. 
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Examples : 

a.  CCM/COM  Build 

b.  Route  Timing  Overlay 

c.  Intervlslblllty  Corridor  Display 

5.  System  response  to  graphic  function  -  Nominally  10  to  16 
selection  calling  for  extensive  seconds 

search  through  the  data  base, 
modification  of  the  displayed 
graphics,  and  special  algorithm 
processing. 

Exampl es : 

a.  Combat  Power  Ratio 

b.  Order  of  Battle  Search 

(NOTE:  Both  examples  Involve 
Identifying  units  meeting  the  IPB 
analyst's  specified  characteristics 
within  areas  defined  by  polygons.) 


3.3.2  Special  Processing  Requirements 

This  section  will  focus  on  special  requirements  for  CPU  processing 
speed  and  performance.  Figure  3.3-1  shows  the  basic  analyst/system 
cycle.  System  activity  Is  Initiated  by  the  analyst  through  his  terminal 
keyboard  selections.  This  system  activity  may  include  accesses  to  the 
data  base,  algorithm  processing,  and  display  processlna  associated  with 
preparing  and  presenting  the  graphic  response  to  the  analyst.  The  analyst 
then  completes  the  total  cycle  by  considering  the  display  presented  and 
selecting  the  next  activity.  For  purposes  of  this  discussion  the  basic 
cycle  can  le  said  to  be  equally  divided  between  manual  activity  by  the 
analyst  (time  periods  labeled  D  and  A)  and  system  response  activity  I 
(time  periods  labeled  B  and  C). 
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Figure  3.3-1.  IPB  Analyst/ System  Basic  Cycle 


From  consideration  of  the  basic  cycle  and  the  system  activities 
It  can  be  said  that  the  requirements  for  CPU  processing  associated 
with  the  special  analyst  aids  (e.g.,  corridor  build,  route  timing, 
combat  power  ratio)  are  not  the  key  driver  In  overall  system  design 
for  the  following  reasons:  (1)  their  occurrence  is  infrequent  relative 
to  other  system  activities,  (2)  any  pure  CPU  processing  of  algorithms 
Is  only  a  portion  of  the  total  system  requirement  and  intermixed  with 
manual  activities.  The  CPU  processing  requirements  associated  with 
these  special  analyst  aids/algorithms  shall  meet  the  overall  inter¬ 
active  system  response  requirements  discussed  in  the  previous  Section 
3.3.1  and  are  considered  non -stressing. 

The  principal  requirements  that  do  stress  and,  thereby,  determine 
CPU  processing  performance  Include  the  following: 

1.  Input  and  Output  data  handling  and  display  management  and 
generation  associated  with  the  display  graphics  subsystem. 

2.  Input  and  Output  data  handling  and  search,  access,  and 
management  associated  with  the  data  base  subsystem. 

3.3.3  Accuracy/Resolution  Requirements 

The  accuracy  requirement  for  locating  a  cursor  on  the  graphic 
screen  measured  In  dimensions  of  the  dlsolayed  graphics  is  a  function 
of  both  the  ability  to  position  the  cursor  and  the  map  scale.  The 
cursor  can  be  positioned  with  relative  ease  by  the  analyst  near  the 
display  point  of  Interest  within  2  millimeters  measured  In  screen 
dimensions.  This  2  millimeters  translates  Into  displayed  graphics 
dimensions  of  100  meters  for  a  1  to  50,000  map  scale.  The  accuracy 
requirement  In  displayed  graphics  dimensions  for  point  location  by 
cursor  for  query  or  symbol  Identification  or  placement  Is  +150  meters 


on  the  1  to  50,000  scale,  +750  meters  on  the  1  to  250,000  scale,  and 
+3000  meters  on  the  1  to  1,000,000  scale. 

The  resolution  requirement  for  map  detail  on  the  graphic  screen  is 
a  function  of  the  map  scale.  The  resolution  requirement  is  described  in 
terms  of  the  ability  to  display  adjacent  parallel  vector  lines.  The 
closest  that  adjacent  parallel  vectors  can  be  positioned  for  display 
allowing  a  minimum  of  one  pixel  space  between  the  vectors  is  62.5  meters 
for  a  640  pixel  screen  line  and  39  meters  for  a  1024  pixel  screen  line 
for  the  1  to  50,000  map  scale.  These  dimensions  provide  the  measure  for 
the  resolution  requirement  for  the  1  to  50,000  map  scale.  In  these  terms 
the  resolution  requirement  is  64  meters  for  the  1  to  50,000  scale,  320 
meters  for  the  1  to  250,000  scale,  and  1280  meters  for  the  1  to  1,000,000 
map  scale. 

3.3.4  Data  Base  Capacity  Requirements 

This  section  includes  data  base  requirements  for  data  items  that 
are  resident  in  the  online,  direct  access  data  base  (disks)  for  use  by 
the  IPB  analyst  in  an  ASAC  at  both  Corps  and  Division.  The  sizing 
estimates  for  the  data  base  are  based  on  the  following: 

1.  A  map  at  any  scale  is  described  by  2,500  16-bH  words  (5,000 
bytes)  per  display.  This  includes  vector  data  p?us  alpha¬ 
numeric  annotations  and  special  symbols. 

2.  Terrain  factor  overlays  require  a  total  of  16  bytes  of  data 
for  each  500  meter  square  area  (1,200  squares  per  display). 

This  means  that  for  a  1:50,000  map  (approximately  20  kilo¬ 
meters  square)  area  the  data  base  requirement  Is  25,600 
bytes  of  data  for  terrain  subfactors. 
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3.  Each  doctrinal  template  is  described  by  a  maximum  of  200 
vector  equivalents  estimated  to  require  a  total  of  2,000 
bytes  of  data. 

4.  Each  IPB  product/overlay  is  described  by  a  maximum  of 
800  vector  equivalents  or  8,000  bytes  of  data. 

The  total  data  base  requirements  for  IPB  at  Corps  and  Division  are 
shown  on  Figure  3.3-2  based  on  the  assumptions  above  and  the  further  assump 
tions  that  the  area  of  interest  for  Corps  is  400  kilometers  square  and 
Division  100  kilometers  square.  The  total  data  base  requirement  for 
IPB  is  estimated,  including  approximately  50  percent  contingency,  at 
30  megabytes  at  Corps  and  5  megabytes  at  Division.  These  estimates  do 
not  represent  the  total  ASAS  data  base  requirement. 
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N.  1PB/ASAS 

REQUIREMENT 

CORPS 

DIVISION 

BI  ECHELON 

OATA  BASE  ITEM 

NUMBER 

Of 

OATA 

ITEMS 

OATA  BASE 
REQUIREMENT 
PER  OATA  ITEM 

K  BYTES 

OATA  BASE 
REQUIREMENT 

K  BYTES 

NtPYBER 

OF 

OATA 

ITEMS 

OATA  BASE 
REQUIREMENT 

PER  OATA  ITEM 

K  BYTES 

DATA  BASE 
REQUIREMENT 

K  BYTES 

MAPS: 

EACH.  ANT  SCALE 

500 

5 

2,500 

SO 

5 

250 

TERRAIN  OVERLAYS: 

20  KM  SQUARE 

400 

56.6 

10.240 

25 

4 

56.6 

640 

OOCTRINAL  TEMPLATES 

400 

2 

800 

200 

2 

400 

IPB  PROOUCTS 

600 

8 

4,800 

300 

8 

2.400 

TOTALS 

18,340 

3,690 

Figure  3.3-2. 
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APPENDIX  A.  IPB  DEFINITIONS 


OPTION 

DOCTRINAL  TEMPLATE 

SNAPSHOT 

CURRENT  SITUATION 

SITUATION  TEMPLATE 

EVENT  ANALYSIS  MATR I X 


One  of  several  alternative  enemy  battle 
plans  -  covers  period  from  his  position 
during  planninq  cycle  to  his  achievement 
of  major  objectives. 

A  qraphlc  showing  composition  (unit  make¬ 
up)  and  disposition  (ground  spacing)  of  an 
enemy  unit  based  on  doctrine  without  con¬ 
sideration  of  terrain  or  weather  factors. 
Will  vary  depending  on  enemy  mission 
(i.e.f  attack,  defense,  etc.). 

Graphic  of  postulated  overall  enemy  and 
friendly  unit  locations  at  an  instant  in 
time  in  a  single  option  on  analyzed  ter¬ 
rain.  Some  5  to  10  snapshots  along 
mobility  corridors  may  be  required  to 
represent  the  execution  of  one  option 
from  inception  to  objective. 

Actual  current  enemy  and  friendly  unit/ 
force  locations  -  as  known  or  estimated 
in  real  time. 

A  portion  of  a  situation  snapshot  showing 
only  those  postulated  unit  locations  at  a 
point  In  time  which  enable  analyst  deter¬ 
mination  that  the  enemy  is  Indeed  pursuing 
this  option — i.e.,  will  allow  him  to  dis¬ 
tinguish  between  this  and  other  options. 

Time  ordered  sequences  of  events  (enemy 
activity  that  is  recognizable  in  near  real 
time  from  a  single  report  or  small  group 
of  reports)  that  Immediately  follow  the 
time  period  represented  by  the  snapshot 
they  relate  to.  They  focus  on  recogniz¬ 
able,  near-term  activities  in  time  sequence. 
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NAI  Specified  portion  of  terrain  that  will 

contain  one  or  more  of  the  events  pre- 
(NAMED  AREA  OF  INTEREST)  dieted  in  the  event  analysis  matrix.  They 

are  normally  identified  during  planning 
cycle,  and  their  locations  are  shown  on 
event  templates. 


EVENT  TEMPLATE  Graphic  layout  of  the  NAI's  associated 

with  a  specific  event  analysis  matrix. 
Indicates  NAI  number  and  location  as  well 
as  sequence  number  of  each  NAI  within  that 
event  analysis  matrix. 

TARGET  ANALYSIS  MATRIX  A/N  tabular  listing  similar  to  event 

analysis  matrix  but  listing  potential 
targets  that  FSE  should  plan  for  and 
monitor  closely  during  time  period  imned- 
iately  following  the  enemy's  achieving 
the  associated  snapshot  force  disposition. 

TAI  Same  as  NAI's  except  showing  areas  listed 

in  the  target  analysis  matrix. 

(TARGET  AREA  OF  INTEREST) 


TARGET  TEMPLATE  Graphic  layout  of  the  TAI's  associated 

with  a  specific  event  analysis  matrix. 

DECISION  SUPPORT  TEMPLATE  A  situation  snapshot  selected  at  a  point 

far  enough  ahead  in  the  option  to  allow 
time  for  friendly  force  actions,  and 
updated  to  reflect  current  knowledge  of 
both  energy  and  friendly  situations. 
Generally,  several  alternatives  are  com¬ 
pared  contrasting  varying  preparation 
times,  geographic  factors,  maneuver  options, 
and  targeting  plans.  The  analyses  also 
develop  what  is  achievable  within  the  time 
constraints.  The  Decision  Support  Template 
is  the  result  of  these  analyses,  and  repre¬ 
sents  an  achievable  friendly  force  action 
in  a  snapshot  format. 

MAP  BACKGROUNDS  These  are  outline  maps  including  only  major 

map  features  such  as  large  bodies  of  water, 
rivers,  bridges,  primary  and  secondary 
roads,  city  and  built-up  area  outlines. 


A-2 


LINES  OF  COMMUNICATION 
Overlay 


BUILD-UP  AREAS  OVERLAY 


TERRAIN  FACTOR  OVERLAY 


WETLANDS  OVERLAY 


CROSSCOUNTRY  MOVEMENT 

OVERLAY - 


This  overlay  provides  mobility  classifi¬ 
cations  for  the  roads,  bridges,  and  rail¬ 
roads.  A  network  of  roads  on  this  overlay 
Is  differentiated  by  colors  to  show 
mobility  of  mechanized  forces. 

This  Is  an  overlay  indicating  the  geo¬ 
outlines  of  metropolitan  areas,  cities 
and  large  towns.  These  areas  are  treated 
as  blocked  or  no-go  zones  when  merged  into 
the  crosscountry  movement  overlay.  When 
merged  with  lines  of  communication  in  the 
combined  obstacles  overlay,  built-up  areas 
may  become  traversible  in  one  of  the  road 
mobility  categories. 

Individual  overlays  for  slope,  vegetation, 
soils  and  wetlands  (hydrology)  are  included 
in  this  set.  The  first  three  are  prepared 
for  display  as  mosaics  in  which  differing 
color  and  intensity  are  used  to  show 
mobility  in  up  to  5  gradations.  The  basic 
mobility  grade  of  each  elemental  square  is 
entered  for  a  "hot  July  day."  Variants  are 
prepared  to  represent  changes  for  other 
seasonal  conditions  (i.e.,  vegetation  state 
in  winter;  soil  classification  in  wet 
season  or  in  sub-freezing  temperatures. 

The  wetlands  overlay  is  a  representation 
of  large  bodies  of  water,  rivers  and 
streams.  Segments  are  differentiated  by 
color  to  show  mobility  of  mechanized  forces 
making  crossings  in  up  to  5  gradations. 
Variants  are  prepared  to  represent  changes 
to  mobility  grades  of  crossings  under 
extreme  flooding  conditions  or  freezing. 

This  overlay  Is  a  composite  of  the  four 
terrain  factor  overlays  plus  the  effects 
of  the  built-up  areas  overlay.  An  algo¬ 
rithm  technique  will  be  designed  to  auto¬ 
matically  combine  the  individual  factors. 
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COMBINED  OBSTACLES 
OVERLAY 


OBSTACLE  PLAN  OVERLAY 


MODIFIED  COMBINED 

OBSTACLEToVOTY 


This  overlay  is  a  composite  of  the  cross¬ 
country  movement  overlay  and  lines-of- 
communication  overlay.  Merging  of  lines- 
of-communication  factors  further  modifies 
the  composite  mobility  picture  or  its 
inverse,  the  combined  obstacles  overlay. 

This  is  a  qraphic  representation  of  the 
friendly  commander's  barrier  plan  showing 
planned  interdiction,  mining  and  demoli¬ 
tion  blocks  to  deny  or  severely  impede 
or  rechannel  enemy  advances. 

This  is  a  version  of  the  combined  obstacles 
overlay  further  modified  to  reflect  the 
effects  of  an  implementation  of  the 
friendly  commander's  obstacle  plan. 


MOBILITY  CORRIDORS  OVERLAY  This  overlay  is  derived  by  analysis  of 

basic  battalion  mobility  over  crosscountry 
terrain  and  over  lines  of  communication. 
The  analyst,  working  directly  on  the 
graphics  display  of  combined  obstacles, 
has  the  capability  to  construct  and  grade 
by  mobility  category  the  corridors  avail¬ 
able  to  enemy  units. 


INTERVISIBILITY  OVERLAY  A  composite  of  terrain,  vegetation, 

elevation  and  atmospheric  factors  which 
depicts  local  average  line  of  sight 
visibility  for  500  meter  grid  boxes. 


INTERV ISIBIL ITY  CORRIDORS  A  qraphic  overlay  derived  from  the  inter- 

QVERLAy  ~  “  visibility  overlay  that  illustrates  in  any 

selected  direction  the  grid  boxes  to  which 
there  is  visibility  from  a  chosen  vantage 
point. 

WEATHER  OVERLAY  This  is  a  graphic  presentation  which  is 

used  to  show  boundaries  of  qeneral  meteo¬ 
rological  conditions  (precipitation,  fog, 
wind  condition)  over  the  areas  of  interest 
to  the  Corps  and  Division  for  use  in 
selecting  factor  overlays  for  mobility 
or  intervisibility. 
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A  large  scale  graphic  showing  an  overall 
enemy  movement  or  operation  (e.g.,  pene¬ 
tration  or  double  envelopment)  based  on 
doctrine  without  consideration  of  terrain 
and  weather  factors.  It  portrays  doctrinal 
spacing  and  composition  of  forces  along  multi¬ 
ple  avenues  of  approach  from  start  point  to 
objective.  It  Indicates  gross  rear  assembly 
areas,  deployment  lines,  lines  of  contact 
and  objective  areas;  it  indicates  gross 
frontages,  width  and  separation  of  avenues 
of  approach  and  width  and  separation  of 
forces  at  the  line  of  contact. 


Tabular  listings  which  doctrlnally  describe 
key  events/ key  targets  that  are  character¬ 
istic  of  enemy  operations  and  maneuvers  and 
can  be  related  to  particular  phases  of  an 
enemy  option  sequence.  A  separate  event 
and  target  menu,  consisting  of  critical 
Indicator/critical  node  type  Items  is  pre¬ 
pared  for  each  major  action  type.  They 
reflect  enemy  doctrine  without  consider¬ 
ation  of  terrain  and  weather.  Their  pur¬ 
pose  is  to  enhance/speed-up  the  preparation 
of  situation  dependent  Event  and  Target 
Matrices  and  Templates,  serving  both  as  a 
reference  for  the  analyst  as  well  as  a 
means  of  saving  key  strokes  In  building 
event/ target  matrixes. 
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A  graphic  depicting  the  avenues  of  approach/ 
routes  of  an  enemy  force  as  it  would  move 
from  an  initial  static  position  to  the 
achievement  of  its  objective.  It  reflects 
a  selection  of  routes  based  on  analysis  of 
enemy  objectives,  enemy  doctrine,  and 
specific  terrain  and  weather  effects  on 
mobility.  It  is  based  on  corridor  rating/ 
route  timing  computations  to  establish 
comparative  transit  times  along  candidate 
routes  and  selection  of  optimum  routes. 

A  graphic  depicting  the  key  points  in  an 
option  where  snapshots  will  be  developed. 

The  key  points  are  translated  into  a  suc¬ 
cession  of  contoured  snapshot  lines  which 
are  transverse  to  and  intersect  the  routes 
of  this  option.  The  lines  represent  the 
locations  of  the  lead  units  across  the 
entire  movement  at  the  successive  key  points. 
Incremental  times  are  shown  between  snapshot 
lines.  The  template  is  based  on  the  Planned 
Routes  Template  and  therefore  reflects  terrai 
and  weather  effects  on  mobility. 


Decision  Alternative  A  graphic  showing  planned  allocation  of 

friendly  units  against  postulated  overall 
enemy  unit  locations.  It  is  developed 
during  the  planning  phase  when  time  permits. 
It  shows  enemy/friendly  force  concentrations 
and  combat  power  ratios  for  an  anticipated 
battle  situation.  It  Incidates  friendly 
unit  doctrinal  locations  rather  than  loca¬ 
tions  placed  on  an  alalyzed  terrain.  More 
careful  unit  placement  as  well  as  deter¬ 
mination  of  what  is  achievable  are  refine¬ 
ments  left  to  the  Decision  Support  Template 
build  step  during  hostilities.  It  indicates 
enemy  unit  planned  locations  as  derived  from 
the  appropriate  snapshot  template. 


APPENDIX  B.  ABBREVIATIONS 


DARCOM 


INSCOM 

IPB 

IPB(A) 

I/V 


All  Source  Analysis  Center 

All  Source  Analysis  System 

Battlefield  Systems  Integration  Directorate 

Crosscountry  Mobility 

Combined  Obstacles  Matrix 

Command  Post 

Combat  Power  Ratio 

Cathode  Ray  Tube 

Combat  Service  Support 

U.S.  Army  Materiel  Development  and  Readiness  Command 

Engineering  Topographic  Laboratory,  Fort  Belvoir 

Enemy  Order  of  Battle 

Field  Artillery 

Forward  Edge  of  Battle  Area 

Fire  Support  Element 

Hierarchical  Input,  Processing,  Output 

U.S.  Army  Intelligence  and  Security  Command 

Intelligence  Preparation  of  the  Battlefield 

Intelligence  Preparation  of  the  Battlefield  (Automated) 

Intervisibility 

Keyboard 

Lines  of  Comnunl cation 
Meteorological 
Military  Grid  Reference 
Motorized  Rifle  Regiment 
Named  Area  of  Interest 
Surface  to  Air  Missile 
Target  Area  of  Interest 

Tactical  Intelligence  Applications  Experimentation 
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TO&E 

TOC 

USAICS 

UTM 


Table  of  Organization  and  Equipment 
Tactical  Operations  Center 
U.S.  Arn\y  Intelligence  Center  and  School 
Universal  Transverse  Mercator 


SYMBOLS  AND  GUIDANCE  FOR  THE  INPUT/FUNCTION/OUTPUT  DIAGRAMS: 


•  Functions  describe  what  the  system  does 

•  Inputs  are  data  items  provided  to  the  function 

•  Outputs  are  data  items  created  or  modified  by  the  function 

•  Functions  and  subfunctions  identified  at  a  high  level 

•  Arrows  connect  specific  inputs  to  their  subfunctions  and 
subfunctions  to  their  specific  outputs 

•  Extended  description  notes  are  used  to  expand  the  Input/ 
Function/Output  diaqrams 

•  Automated  functions  (supported  principally  by  software)  are 
differentiated  from  functions  supported  principally  by  the 
human  in  the  man/machine  interface.  Non-automated  functions 
are  identified  as  analyst  performed  functions. 

•  Functions  are  described  in  diagrams  labeled  as  figures,  and 
shown  below,  with  multiple  sheets  used  as  necessary  to  com¬ 
plete  a  figure  and  with  extended  description  notes  included 
on  the  last  sheet  of  a  fiqure. 

NOTES:  1.  Data  item  connectors  use  letters  only  when  all  related 
connectors  are  on  the  same  sheet. 

2.  Data  item  connectors  use  letters  with  reference  to  sheet 
numbers  when  all  related  connectors  are  not  on  the  same 
sheet.  In  the  example  below,  at  least  three  sheets  are 
required  to  fully  descirbe  the  function. 

Fiqure  3-X  Function: _ Sheet _ of  n 


INPUT 


FUNCTION 


OUTPUT 

Sheet  3 


Sheet  1 


Extended  Description  Notes: 

T 

2. 
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SYMBOLS  FOR  THE  INPUT/FUNCTION/OUTPUT  DIAGRAMS: 


A/N  CRT 


Information  input  by  online  keyboards: 

•  A/N  KB  •  Cursor 

•  Function  KB  •  Graphic  Tablet 

Online  visual  indicators: 

•  A/N  CRT  •  Plotter 

•  Graphic  Color  CRT  •  Printer 

Hardcopy  devices: 

•  Printers 


Information  provided  by  online  storage: 
•  Disk  •  Magnetic  Tape 


Parameter 


Function 


Information  provided  by  magnetic  tape 


Information  provided  by  card  medium 


Parameter  independent  of  medium 


Function  or  Subfunction 

principally  automated/performed  by  software 


1  Analyst  ** 
L  Junction  .  J 


Function  or  Subfunction 

principally  non-automated/performed  by  analyst 
Data  Item  Connector  -  same  sheet 

Data  Item  Connector  -  off  sheet,  same  figure 
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APPENDIX  C 


WEATHER  UPDATE  MENU  TABLES 


APPENDIX  C.  WEATHER  UPDATE  MENU  TABLES 


Section  3. 1.2.1  describes  how  weather  inputs  are  entered  into  the 
system  to  enable  building  sets  of  terrain  overlay  or  terrain  overlay 
composites  that  take  weather  conditions  into  account.  This  appendix 
includes  the  factor  data  tables  required  for  interpreting  the  effects 
of  the  weather  inputs  on  the  basic  terrain  data  as  stored  in  the  data 
base. 


Carrying  weather  factor  data  in  a  series  of  tables  offers  the 
following  advantages: 

•  The  factor  data  is  easily  modified  by  non-programming 
personnel 

•  Table  look-up  processing  offers  computational  speed 
advantages  over  alternate  methods 

•  Allows  basic  terrain  data  to  be  retained  in  the  data  base 
in  source  terms  for  easy  traceability. 

The  following  sections  Include  the  actual  data  tables  and  a  brief 
summary  of  the  contents  of  each. 
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C.l  INTERVISIBILITY  OVERLAY  INITIALIZATION  TABLES 


The  following  seven  tables  shall  be  used  to  produce  all  IPB(A) 
intervisibility  graphic  overlays  described  elsewhere  in  this 
document: 

Table  1.1.1  -  lists  the  tree  height  values  that  must  be  added 

to  terrain  elevation  for  computing  Intervisibility 
corridors  during  winter  (foliaged  tree)  months 

Table  1.1.2  -  lists  the  tree  height  values  that  must  be  added 

to  terrain  elevation  for  computing  intervisibility 
corridors  during  sunnier  months 

Table  1.2.1  -  lists  the  data  as  discussed  in  Section  3. 1.1. 3, 
i.e.,  vector  data  table  with  UTM/MGR  coordinates 
(not  Included  in  appendix) 

Table  1.2.2  -  an  empty  set 

Table  1.3  -  contains  the  visibility  range  factor  to  be  used 

for  computing  a  visibility  range  overlay 
(not  Included  In  appendix) 

Table  1.4  -  lists  the  translation  of  ETL  vegetation  data  to 

IPB(A)  vegetation  categories  for  use  in  computing 
an  intervisibility  mosaic 

Table  1.5  -  lists  the  translation  of  ETL  surface  configurations 

and  built-up  area  data  to  IPB(A)  categories  for  use  in 
computing  an  Intervisibility  mosaic 
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Table  1.4.  Intervisibility  Mosaic  -  Vegetation 


C.2  CCM  OVERLAY  INITIALIZATION  TABLES 


The  following  eleven  tables  shall  be  used  to  produce  all  IPB(A) 
mobility  graphics  overlays  described  elsewhere  in  this  document: 

Table  2.1.1  -  lists  the  translation  of  ETL  soil  data  to  IPB(A) 
soil  categories  for  use  in  either  graphically 
displaying  soils  or  computing  a  CCM  for  graphic 
display  when  the  soil  in  the  area  is  dry  but 
there  is  flood  plain  flooding 

Table  2.1.2  -  used  for  same  purpose  as  Table  2.1.1  but  here  there 
is  no  flood  plain  flooding  and  the  soils  are  dry 

Table  2.2.1  -  used  for  the  same  purpose  as  Table  2.1.1  but  here 
the  soil  condition  in  the  area  is  wet  and  there  is 
flood  plain  flooding 

Table  2.2.2  -  used  for  the  same  purpose  as  Table  2.1.1  but  here 
the  soils  are  wet  and  there  is  no  flood  plain 
flooding 

Table  2.3.1  -  used  for  the  same  purpose  as  Table  2.1.1  but  here 
the  soils  are  saturated  and  there  is  flood  plain 
fl ooding 

Table  2.3.2  -  used  for  the  same  purpose  as  Table  2.1.1  but  here 
the  soils  are  saturated  and  there  is  no  flood  plain 
flooding 
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Table  2.1.1.  Crosscountry  Movement  -  Flooding  and  Dry 


CROSSCOUNTRY  MOBILITY 

CYAN 

YELLOW 

MAGENTA 

RED 

GREEN 

INHIBITED 

SLOW 

VERY  SLOW 

STOP 

GO 

1/2 

1/4 

1/12 

0 

OOCTRINAL 

DOCTRINAL 

DOCTRINAL 

DOCTRINAL 

DOCTRINAL 

SPEED 

SPEED 

SPEED 

SPEED 

SPEED 

NUMBERS  COOED  WITH  MINUS  (-)  ARE  FLOOD  PLAIN 


Table  2.1.2.  Crosscountry  Movement  -  Non-Flooding  and  Dry 


ETL 

SOILS 

KEY 

CROSSCOUNTRY  MOBILITY 

GREEN 

GO 

DOCTRINAL 

SPEED 

CYAN 

INHIBITED 

1/2 

DOCTRINAL 

SPEED 

YELLOW 

SLOW 

1/4 

DOCTRINAL 

SPEED 

MAGENTA 

VERY  SLOW 

1/12 

DOCTRINAL 

SPEED 

RED 

STOP 

0 

DOCTRINAL 

SPEED 

1 

1 

2 

1 

3 

1 

4 

1 

5 

1 

6 

1 

7 

1 

a 

1 

9 

1 

10 

1 

11 

1/4 

12 

1 

13 

1 

14 

0 

15 

0 

16 

1 

1- 

1 

2- 

1 

3- 

1 

4- 

1 

5- 

1 

6- 

1 

7- 

1 

8- 

1 

9- 

1 

10- 

1 

11- 

1/4 

12- 

1 

13- 

1 

14 

0 

15- 

0 

16- 

1 

NUN8CTS  COOED  WITH  MINOS  (-)  ARE  FLOOD  PLAIN 
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Table  2.3.2.  Crosscountry  Movement  -  Non-Flooding  and  Saturated 


CROSSCOUNTRY  MOBILITY 

CYAN 

YELLOW 

MAGENTA 

REO 

GREEN 

INHIBITED 

SLOW 

VERY  SLOW 

STOP 

ETL 

GO 

1/2 

1/4 

1/12 

0 

SOILS 

DOCTRINAL 

DOCTRINAL 

DOCTRINAL 

DOCTRINAL 

DOCTRINAL 

KEY 

SPEED 

SPEED 

SPEED 

SPEED 

SPEED 

NUMBERS  COOED  WITH  MINUS  (-)  ARE  FLOOD  PLAIN 
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Table  2.4.1  -  used  for  the  same  purpose  as  Table  2.1.1  but  here 
the  soils  are  frozen  and  there  Is  flood  plain 
flooding 


Table  2.4.2  -  used  for  the  same  purpose  as  Table  2.1.1  but  here 
the  soils  are  frozen  and  there  is  no  flood  plain 
fl ooding 

Table  2.5.3  -  lists  degradation  factors  to  be  used  to  compute  the 
CCM  as  a  function  of  snow  depth 

Table  2.6  -  lists  the  IPB(A)  mobility  conversion  factors  for 

vegetation  as  a  function  of  ETL  classification 

Table  2.7  -  lists  the  IPB(A)  mobility  conversion  factors  for 

surface  configuration  and  built-up  areas 


C.3  LOC  OVERLAY  INITIALIZATION  TABLES 


Three  tables  shall  be  required  to  Initialize  roads  as  a  function 
of  ambient  conditions: 

Table  3.1  -  selects  the  doctrinal  rate  degradation  factor  as  a 

function  of  day/night  movement 

Table  3.2  -  selects  the  doctrinal  movement  rate  degradation 

factor  as  a  function  of  road  condition:  dry,  wet, 
ice  covered,  snow  covered 

Table  3.3  -  selects  the  roads  to  be  affected  by  Table  3.2  factors. 
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Table  2.4.1.  Crosscountry  Movement  -  Flooding  and  Frozen 


CROSSCOUNTRY  MOBILITY 

CYAN 

YELLOW 

MAGENTA 

RED 

GREEN 

INHIBITED 

SLOW 

VERY  SLOW 

STOP 

ETL 

GO 

1/2 

1/4 

1/12 

0 

SOILS 

DOCTRINAL 

DOCTRINAL 

DOCTRINAL 

DOCTRINAL 

DOCTRINAL 

KEY 

SPEED 

SPEED 

SPEED 

SPEED 

SPEED 

1 

1 

1 

1 

1 

1 

1 

1 

8 

1 

9 

1 

10 

1 

11 

12 

1 

1/2 

13 

1 

14 

1/4 

IS 
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0 

0 

0 

0 

0 

0 
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0 

0 

10- 

0 

11- 

0  ! 
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0 

14- 

0 

IS- 

0 

16- 

0 

NUMBERS  CODED  WITH  MINUS  (-)  ARE  FLOOD  PLAIN 
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Table  2.5.3.  Snow  Imoact 


FOR  CCM,  IF  SNOW  DEPTH  IS: 


0.00 

to 

12.7 

cm 

multiply  by 

1.00 

12.7 

to 

25.4 

cm 

II  II 

0.50 

25.4 

to 

50.8 

cm 

II  II 

0.25 

50.8 

to 

76.2 

cm 

II  II 

1/12 

>  76.2  cm 


II 


0 


Table  2.6.  Crosscountry  Movement  -  Vegetation 
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Table  2.7.  Effect  of  Surface  Configuration  for  CCM 


Table  3.1  Time 


DAY  -  Use  Doctrinal  Rate  =  X 
NIGHT  -  Use  Doctrinal  Rate  =  -jj— 
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DRY 

WET 

ICE 

SNOW 


Table  3.2  Road  Condition 


Multiply  Table  Selection 
Multiply  Table  Selection 
Multiply  Table  Selection 


3.1 

by 

1.0 

3.1 

by 

0.9 

3.1 

by 

0.0 

0  to  12.7 

12.7  to  25.4 
25.4  to  50.8 

50.8  to  76.2 
>  76.2 


Multiply  Table  Selection  3.1  by  1.00 
Multiply  Table  Selection  3.1  by  0.50 
Multiply  Table  Selection  3.1  by  0.25 
Multiply  Table  Selection  3.1  by  1/12 
Multiply  Table  Selection  3.1  by  0.0 
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Table  3.3  Road  Class 

Modify  ALL  Road  Classes  According  to  Table  Selection  3.2 
Modify  AUTOBAHN  According  to  Table  Selection  3.2 
Modify  PRIMARY  ROAD  According  to  Table  Selection  3.2 
Modify  SECONDARY  ROAD  According  to  Table  Selection  3.2 
Modify  TERTIARY  ROAD  According  to  Table  Selection  3.2 
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C.4  COM  CURRENT  WEATHER  UPDATE 


Table  4.0  lists  the  degradation  factors  to  be  used  when  listed 
precipitation  effects  are  expected  to  occur  in  the  named  area  of 
interest. 
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Table  4.0  COM  Current  Weather  Degradation  Factors 


NONE 

LIGHT  RAIN 

MODERATE  RAIN 

HEAVY  RAIN 

LIGHT  FREEZING  RAIN 

MODERATE  FREEZING  RAIN  - 

HEAVY  FREEZING  RAIN 

LIGHT  SNOW 

MODERATE  SNOW 

HEAVY  SNOW 


Degrade  CCM/LOC  by 

1.0 

Degrade  CCM/LOC  by 

1.0 

Degrade  CCM/LOC  by 

0.5 

Degrade  CCM/LOC  by 

0.25 

Degrade  CCM/LOC  by 

0.25 

Degrade  CCM/LOC  by 

0.1 

Degrade  CCM/LOC  by 

0.0 

Degrade  CCM/LOC  by 

1.0 

Degrade  CCM/LOC  by 

0.5 

Degrade  CCM/LOC  by 

0.1 
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APPENDIX  D 


SLIDING  WINDOW  SEGMENT  COMPUTATION 
(CROSSCOUNTRY  CORRIDOR) 


APPENDIX 


1. 


D.  SLIDING  WINDOW  SEGMENT  COMPUTATION  (CROSSCOUNTRY  CORRIDOR) 


Referring  to  Section  3. 1.2. 2. 2,  the  width  of  the  test  corridor 
shall  be  no  larger  than  the  maximum  width  of  a  doctrinal  front 
of  the  echelon  expected  to  traverse  the  corridor.  For  example, 
if  a  battalion  front  is  nominally  1.5  kilometer  and  maximally 
2.5  kilometers  In  crosscountry  movement  (as  opposed  to  deployed 
for  combat),  the  test  corridor  width  should  be  2.5  kilometers. 

Since  the  length  of  the  sliding  window  equals  the  width  of  the 
test  corridor,  the  lenqth  of  the  window  equals  the  maximum 
width  of  the  front  of  the  echelon  expected  to  traverse  it. 

The  corridor  width  (window  length)  shall  not,  however,  be 
hard  programmed.  Default  values  shall  be  programmed  such 
that  the  analyst  can  change  them  if  he  suspects  that  doctrine 
is  either  not  being  followed  or  has  been  changed. 

The  rating  value  of  a  single  window  area  segment  of  a 
corridor  is  defined  as  follows: 


A 


/Units  \ 

lur/ 


(i) 


By  appropriate  substitution  this  can  be  found  to  be 
equivalent  to: 


A 


/Units  \ 
V  ~ Rr  / 


(2) 


0-1 


where , 


V,.  *  average  speed  permitted  in  the  window  (km/hr) 

W  *  calculated  width  of  the  corridor  (km/unit  type) 
c 

WQ  *  doctrinal  width  of  front  of  input  echelon  (km/ 
unit  type).  This  should  be  a  default  value 
that  can  be  changed  by  analyst  input. 

DD  *  doctrinal  length  of  input  echelon  (km/unit  type). 

This  should  be  a  default  value  that  can  be 
chanqed  by  analyst  input. 

*  the  length  of  the  window  as  determined  by  the 
echelon  expected  to  travel  the  corridor.  Should 
have  default  value  that  can  be  changed  by  analyst 
input. 

C.j.  *  the  total  number  of  blocks  contained  in  the 
window 

*  the  sum  of  the  normalized  speed  values  of  the 
individual  blocks  contained  in  the  window.  That 
is,  go  =  1.0,  inhibited  *  0.5,  slow  =  0.25,  very 
slow  =  0.0825,  no  go  *  0.00. 

Sp  *  doctrinal  speed  (e.g.,  12km/hr)  changeable 
default  value. 

It  should  be  noted  that  Lw,  Wp,  Dp  and  Sp  In  equation  (2)  are 
all  prestored  table  look-ups.  The  first  three  being  a  function 
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of  echelon  and  are  Input  automatically  as  initializing  data 
when  the  analyst  selects  the  echelon.  Vy  is  a  simple  sum  of 
the  block  values  and  Cy  is  the  total  number  of  blocks. 

The  rating  of  the  window  segment  is  then  determined  by  com¬ 
paring  the  calculated  value  of  "A"  in  equation  2,  to  a  table 
like  that  contained  in  Figure  D-l .  In  the  figure,  with 
the  assumption  indicated  in  the  footnotes  it  is  seen  that  for 
a  regiment  traversing  the  nominated  corridor  and  the  value 
of  "A"  determined  to  be  2.5  battalions/hour,  the  corridor 
segment  is  rated  as  inhibited  and  painted  cyan. 


Figure  D-1.  Corridor  Rating  Boundaries/Speed  Conversions 
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APPENDIX  E.  TERRAIN  SOURCE  DATA  REQUIREMENTS  (EXISTING  DATA) 


Five  categories  of  terrain  data  shall  be  required  for  the  automated 
IPB  system:  terrain  elevation,  surface  configurations,  vegetation, 
soils,  wetlands  and  built-up  areas.  For  areas  where  terrain  analysis 
has  been  completed  for  other  purposes  and  the  data  exists  in  more 
detailed  conventional  form,  it  shall  be  supplied  on  magnetic  tape  and  in 
a  form  shown  in  Figure  E-l.  The  figure  shows  that  the  acetate  overlays, 
commonly  provided  by  ETL,  are  treated  as  a  coarse-grained  digital  terrain 
model  with  an  implicit  cartesian  coordinate  matrix  composed  of  the 
mobility  class  values  of  the  various  terrain  subfactor  categories.  The 
1:50,000  scale  sheets  shall  be  digitized  to  500  meter  x  500  meter  squares 
center- to-center  and  the  UTM/MGR  coordinate  origins  used  shall  be  common 
to  all  maps  including  the  LOC  map  data  (see  paragraph  3. 1.1.1).  Each 
500  meter  square  shall  be  digitized  to  include  data  relative  to  the  five 
categories  (vegetation,  soils,  etc.)  plus  MGR  coordinate  location  of  the 
square.  Each  category  of  data  shall  be  classified  and  stored  according 
to  the  current  ETL  code: 

•  Surface  Configuration  -  12  classes  (6  classes  of  slope  plus 
escarpments,  fills,  cuts,  quarries,  mines,  embankments) 

•  Vegetation  -  46  classes  (cropland,  grassland/pasture/meadow, 

12  classes  of  coniferous  forest,  12  classes  of  deciduous 
forest,  12  classes  of  mixed  forest,  forest  clearing,  grass¬ 
land  and  scattered  trees,  orchards/nurseries,  hop-gardens/ 
vineyards,  swamps /mars he s ,  brushland,  bare  ground,  peat 
cuttings) 
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Figure  E-l.  Terrain  Subfactor  Digitization 


•  Soils  -  32  classes  (16  soil  groups  classed  according  to  the 
Unified  Soil  Classification  System  (USCS)  plus  each  class 
coded  for  flood  plain 

•  Built-Up  -  2  classes  (built-up  or  not). 

Again,  from  Figure  E-l,  It  Is  seen  that  15  characters  shall  be 
required  to  digitally  categorize  and  classify  each  500  meter  x  500  meter 
square  block.  This  is  approximately  equivalent  to  half  a  million  char¬ 
acters  to  digitize  a  100  x  100  kilometer  area. 

With  the  data  digitized  and  coded  in  this  fashion  a  number  of  over¬ 
lays  can  be  built  on  the  graphic  display  by  the  analyst  through  the 
automated  IPB  system.  These  shall  include,  but  not  be  limited  to,  the 
following: 

• 

a 

corri dors 


Slope  • 
Vegetation  • 
Soils  • 
Built-Up  Areas  • 


Intervisibility  Overlay 

CCM 

COM 

CCM,  L0C  and  Intervisibility 


The  technique  for  translating  the  ETL  subfactor  terrain  data  into 
the  five-part  IPB(A)  code  shall  be  accomplished  as  discussed  in  the 
reference  materials  (TIAX  Final  Report  Phase  A,  TIAX  Interim  Report 
Phase  II).  Section  3. 1.2. 2  in  this  document  describes  how  the  data  is 
used  to  build  the  various  terrain  composites  required  for  the  IPB 
process. 
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APPENDIX  F.  ADDITIONAL  ANALYST  AUTOMATION  AIDS 


Besides  the  standard  IPB  system  graphics  and  data  base  management 
software  functional  capabilities,  there  are  several  automated  aids  to 
the  analyst  that  have  been  Identified  In  the  course  of  IPB(A)  develop¬ 
ment  but  not  thoroughly  specified  due  to  time/resource  limitations. 
They  are  described  here  In  sufficient  detail  to  form  the  basis  for 
further  Implementation.  The  aids  described  In  this  appendix  are: 

•  Combat  power  ratio 

•  Symbol  matching 

•  Symbol  replot 

•  Situation  template  file  search. 


F.l  COMBAT  POWER  RATIO 

This  automated  aid  Is  Intended  to  assist  the  analyst  In  rapidly 
performing  the  comparison  of  enemy  to  friendly  forces  considering  there 
are  a  number  of  occasions  In  the  6-2  and  G-3  uses  of  IPB  when  that 
comparison  Is  required. 

Depending  on  the  nature  of  the  requirement,  the  IPB 
analyst  will  call  a  current  situation  graphic  display  or  a  snapshot  or 
a  decision  alternative  template  (all  of  which  contain  both  enemy  and 
friendly  forces).  In  any  case  he  must  have  the  appropriate  map  back¬ 
ground  In  addition  to  the  particular  military  scene  In  order  to  obtain 
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UTM  coordinates  from  the  graphics  CRT.  He  reviews  the  military  scene 
displayed  and  decides  whether  or  not  it  is  as  complete  as  he  desires. 

For  example,  have  all  units  In  the  enemy  ground  order  of  battle  been 
accounted  for?  If  required,  he  may  review  the  OB  by  executing  a 
standard  data  base  management  query  against  the  ENSIT  data  base  and 
compare  the  output  on  the  A/N  CRT  with  the  graphic  display.  If  he 
elects  to  modify  the  graphic  display,  he  uses  standard  graphics  functions 
to  move  flags,  build  new  ones  or  delete  unwanted  ones.  When  the  graphics 
display  of  the  military  situation  is  as  desired,  the  analyst  defines  the 
geographic  area  and/or  the  group  of  military  units  (flags)  on  the 
graphic  display  for  which  the  combat  power  ratio  will  be  calculated  by 
drawing  a  polygon  outlining  the  area/flags  of  interest. 

By  means  of  the  function  keyboard,  the  analyst  initializes  the 
computational  portion  of  this  function.  The  graphics  software  converts 
screen  coordinates  to  UTM,  for  each  corner  of  the  polygon  and  transfers 
them  to  the  A/N  data  base.  Similarly  locations  and  characteristics  of 
the  flags  or  symbols  are  transferred  from  the  graphics  to  the  alpha¬ 
numeric  data  base.  If  the  initial  problem  Is  applicable  to  the  current 
situation,  the  A/N  data  base  already  has  unit  identity  and  location  data. 

In  the  next  step  the  specified  enemy  units  are  converted  to  equiva¬ 
lent  friendly  units  in  order  to  permit  proper  comparison.  A  total  of 
enemy  and  friendly  units  Is  computed.  The  system  will  allow  other  input 
factors  to  be  considered  in  the  totaling  process.  For  example,  the 
analyst  may  elect  to  modify  unit  count  by  the  degree  of  effectiveness 
assigned  to  each  unit  counted.  After  the  equivalent  enemy  and  friendly 
totals  are  calculated  the  arithmetic  ratio  is  made  and  the  results  are 
automatically  displayed  on  the  A/N  CRT. 
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F.2  SYMBOL  MATCHING 


During  the  IPB  build  process  the  analyst  must  compare  two  graphic 
displays  (templates)  in  order  to  determine  uniqueness  or  special  quality. 
One  example  is  in  the  snapshot  build  process  when  flags/symbols  unique 
to  the  option  will  be  given  a  different  color  than  those  common  to  more 
than  one  option.  Another  example  is  in  decision  alternative  template 
building  when  desired  number/ location  of  a  friendly  unit  is  to  be  differ¬ 
entiated  from  the  current  location--using  different  colors  and/or 
blinking.  The  IPB  system  aids  the  analyst  by  automated  comparison  in 
lieu  of  visual. 

The  symbol  matching  process  consists  of  two  basic  steps:  first, 
the  primary  or  controlling  flag/symbol  and  area  of  interest  must  be 
Identified  so  that  the  system  knows  how  to  make  comparisons  and  what 
action  to  take;  second,  a  search  must  be  conducted  for  like  units  and 
when  they  are  found  the  fact  that  they  are  common  must  be  Indicated. 

The  analyst  has  the  two  overlays  merged  on  the  screen  which  con¬ 
stitute  the  comparison  problem.  The  overlays  must  be  color  contrasted, 
must  be  at  the  same  scale,  and  must  overlay  the  same  geographic  area 
although  no  map  background  is  necessary.  The  IPB(A)  system  links  each 
overlay  to  a  specific  map,  therefore  UTM  coordinates  associated  with  the 
two  overlays  are  available  within  the  system. 

The  analyst  defines  the  area  of  1nterest--the  boundaries  of  the 
search— and  Inputs  the  parameters  which  determine  match  qualification, 
i.e.,  flag/symbol  must  be  within  X  kilometers  of  the  primary  In  order 
to  qualify  as  a  match.  The  function  keyboard/ cursor  provide  the 
analyst  the  tools  to  accomplish  these  actions. 

The  matching  function  must  be  tailored  to  the  specific  activity. 

An  example  of  one  approach  follows. 
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The  system  scans  the  search  area  to  find  the  first  primary  symbol. 

It  then  does  a  circle  search  at  the  prescribed  radius  around  that 
symbol's  location.  If  another,  like  symbol  is  found  it  is  compared  to 
the  primary  for  type,  echelon,  etc.,  and  for  color.  If  a  legal  match 
is  found,  the  system  deletes  the  secondary  symbol,  if  not  search  con¬ 
tinues.  If  no  legal  match  is  found,  the  primary,  unmatched  symbol  is 
blinked.  The  search  moves  to  the  next  primary  symbol,  etc.,  when  the 
matching  is  completed  the  system  automatically  deletes  the  area  polygon. 
The  resulting  display  on  the  graphic  CRT  shows  the  primary  symbols  in 
their  original  color,  unblinking  if  matched,  blinking  if  unmatched,  and 
any  secondary  symbols  not  matched  to  a  primary  in  their  original  color 
and  locations. 

If  a  third  overlay  is  now  to  be  compared  to  the  primary,  the  blink¬ 
ing/non-blinking  quality  of  the  primary  symbol  would  be  considered  in 
the  matching  logic  as  necessary.  Also  use  of  a  third  color  in  lieu  of 
blinking  Is  an  alternative  way  to  indicate  those  primary  matched/ unmatched 
symbol s . 

F.3  SYMBOL  REPLOT 

During  the  build  process  and  also  the  G-3  use  phase  of  IPB  there 
are  a  number  of  situations  wherein  the  analyst  performs  detailed  analysis 
with  IPB  products  at  a  1:50,000  scale.  Once  all  geographic  areas  of 
concern  have  been  analyzed  and  the  results  reflected  by  positioning 
flags/symbols  on  overlays  at  that  scale,  the  analyst  must  aggregate  the 
total  by  building  or  modifying  a  1:250,000  scale  overlay.  For  example, 
having  built  a  decision  alternative  template  (1:250,000  scale)  to  the 
degree  of  accuracy  possible  at  that  scale,  the  analyst  may  look  at  unit 
locations  more  precisely  using  terrain  features.  Intervisibility  route 
timing,  etc.,  at  the  1:50,000  scale.  Then  he  may  want  to  return  to  the 
1:250,000  template  and  make  adjustments  that  reflect  those  made  on  the 
1:50,000  scale. 
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The  automated  aid  called  symbol  replot  supports  the  analyst  in 
retaining  a  symbol  type  and  location  when  moving  to  a  smaller  scale. 

With  the  completed  1:50,000  scale  display/overlay  on  the  graphic  CRT 
the  analyst  initializes  the  report  function.  He  uses  the  cursor  to 
identify  a  symbol/flag.  The  system  automatically  stores  the  symbol 
characteristics  and  UTM  location  in  a  temporary  data  set.  The  analyst 
acquires  all  the  flags/symbols  by  cursor  that  he  wants  to  be  included 
in  the  larger  area  overlay.  He  then  calls  the  1:250,000  overlay  he 
wants  to  adjust.  The  system  uses  the  temporary  data  set  to  add  these 
flags/symbols  to  the  larger  area  scene  now  on  the  graphics  CRT.  The 
analyst  then  uses  standard  add,  move,  delete  symbol  capability  to  make 
final  adjustments  to  the  1:250,000  scale  template. 

F.4  SITUATION  TEMPLATE  FILE  SEARCH 

The  IPB  analyst  builds  and  stores  many  situation  templates  in  the 
course  of  planning  several  enemy  options.  During  the  use  phase  he 
frequently  needs  to  know  what  situation  templates  he  has  in  a  certain 
area.  This  section  describes  a  system  aid  to  meet  this  need.  The 
analyst  Identifies  a  geographic  location  of  interest  for  a  situation 
template  search  by  positioning  the  cursor  on  a  display  that  Includes  a 
map  background.  The  analyst  then  initializes  the  function  by  means  of 
the  function  keyboard.  The  cursor  position  (in  UTM)  is  used  to  set  the 
parameter  for  a  search  of  the  graphics  data  base.  Each  situation 
template  is  linked  to  a  map  which  therefore  enables  the  UTM  boundaries 
of  that  template  to  be  Identified  and  hence  used  to  determine  if  the 
cursor  UTM  coordinates  fall  within  the  boundaries  of  that  template  or 
not.  If  the  situation  template  qualifies  the  system  extracts  other  data 
from  its  data  base  record,  l.e.,  Identify,  lower  left  corner  UTM 
coordinates  and  other  significant  Information.  The  extracted  data  Is 
stored  temporarily  on  a  data  set  until  all  situation  templates  In  the 
data  base  have  been  checked.  Then  a  prestored,  data  base  management 
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query  is  executed  against  that  data  set  and  the  results  displayed  on  the 
A/N  CRT.  The  resulting  display  lists  the  Situation  Templates  in  the 
file  that  include  the  specified  cursor  location  as  a  point.  The  analyst 
may  then  access  the  templates  by  number. 
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